[swift-server-dev] Next HTTP API meeting

Alex Blewitt alblue at apple.com
Thu Mar 23 05:55:20 CDT 2017

> On 23 Mar 2017, at 10:18, Logan Wright <logan at qutheory.io> wrote:
> Alex,
> Since this is a parser, I'd opt for something more general like `[String: String?]` (would need to check on the optional there), because that's how the parser will likely receive it, ie:
> Key: Value\r\n
> Other-Key: OtherValue\r\n

The problem is that the HTTP spec permits:

Key: Value\r\n
Other-Key: OtherValue\r\n
Key: Different Value\r\n

and this isn't possible with a single dictionary as an implementation. So instead of constraining the implementation to a particular assumption about how implementations may need to use it, define the API for how you want to interact with it, e.g.:

https://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getHeader(java.lang.String) <https://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getHeader(java.lang.String)>
https://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getHeaders(java.lang.String) <https://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getHeaders(java.lang.String)> 
https://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getHeaderNames() <https://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getHeaderNames()> 

In other words, make the simple case easy but permit the additional cases as well.

> Then inside the initializer, the model would modify it, create arrays or custom headers models as they see fit. This allows the server side apis to opt out out of taking too many opinions and lets frameworks decide what's best for them. Many want simple [String: String], at Vapor we use [HeaderKey: String] for case insensitivity, some might want something that's considered more "correct" as [CaseInsensitive: [String?]?] or something.

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? 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:


One could always provide the default case-sensitive view on the headers as well:


That API, while it would be satisfied by [String:String?], doesn't imply that it must be [String:String?].

Furthermore it's worth noting that [String:String?] is not order preserving on the headers, while HTTP is an ordered sequence of such headers. I doubt there's anyone who would need to know that but it's an example of something that an API may need to provide that can't be done with a trivial implementation.

> All of these are arguably valid, so I think taking the approach of Parser's perspective and how things are received would be a good paradigm to strive towards.

I'm not clear what you're referring to here; do you have an example?

> The one thing missing in my example is order, which perhaps `[(String, String?)]` would be better if there are significant implications for order here to an end model. 

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170323/b2d176e2/attachment.html>

More information about the swift-server-dev mailing list