[swift-server-dev] Next HTTP API meeting

[Helge Heß]

On 23 Mar 2017, at 11:55, Alex Blewitt via swift-server-dev <swift-server-dev at swift.org> wrote:
> Do you want/need [String:String?], or do you just want something as simple as a data structure that takes a String subscript and returns a String?

+1 for the latter (do not use a Dictionary, or if you do, do not use String as the key, as it has to be case insensitive)

A protocol could also just require the complex variant, say:

  func iterateValues(for key: String, valueCallback: (String)->Void)

and provide the convenience things, like

  subscript[key: String] -> String { … }

as extensions based on top of that.

> In fact you can have two views (much like different views exist on strings for e.g. utf8 and utf16) that provide you the case sensitivity or not

-1 HTTP headers are always case insensitive:

  https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
  "Field names are case-insensitive."

> This is why I think defining the headers to be <a specific data structure> is impractical, and using a protocol to define how you interact with them is more appropriate.

+1. Well, I think a specific data structure may be OK, but it should not be a `Dictionary<String, String>`, just behave like one as a convenience.

hh

P.S.: I really don’t want to complicate the discussion, but doesn’t someone else feel that the overhead of String is way too big here (for such a core library) and that significant space and time savings could be accomplished by using enums and such? (Swift has no String.intern, right? - but even just a 64bit ptr could often almost fit all header keys + method)