[swift-server-dev] HTTPMethod, was: Re: Next HTTP API meeting

[George Leontiev]

A few quick notes on headers:
- [HeaderKeyValuePair] (an array) may better support repeated keys and trailing headers at the parser level than a dictionary would (plus it would be more efficient to skip the dictionary representation if you interpret headers in order)
- Parsers may benefit from skipping the string representation entirely when parsing HTTP2 directly from HPACK. This may be an argument for enums, and it could even be standardized by providing explicit cases for HPACK static-lookup-table headers and then custom headers would use an associated value.
- I think types for header values would be very useful (like standardizing if a MediaRange accepts a MediaType) as well as key-value type associations ("Content-Type" is always MediaType). This extra safety can be opt-in extensions to either HeaderKeyValuePair or the Request/Response.
- Finally, if we want to standardize a dictionary-like access pattern we can provide a utility method to "normalize" a list of HeaderKeyValuePairs which would resolve duplicates.

> On Mar 23, 2017, at 5:35 AM, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> I think it might be lowercase to stick w/ the official Apple swift 3 guidelines, but definitely agree on some type of extensibility. Currently I've been naming that 'other' in general. With that said, that's kind of why I included a String in my proposal. If we can focus on the actual components of the parser and let users define models as much as possible, then it offloads a lot of our opinions into respective frameworks. In terms of Method, here's how I currently have it for discussion:
> 
> enum Method {
>     case get, post, put, patch
>     case other(String)
> }
> 
> I think in addition to adding new official methods (I might be wrong here, need to double check) but I believe server/clients can define any method they might want to use between them, so I completely agree with you that whatever we have will definitely need some type of extensibility (whatever we call it) to conform to spec.
> 
>> On Thu, Mar 23, 2017 at 12:12 PM Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
>> On 23 Mar 2017, at 11:18, Logan Wright via swift-server-dev <swift-server-dev at swift.org> wrote:
>> > some types that I think are pretty unambiguous like HTTPMethod
>> 
>> May I ask how that would look like in your opinion? I was thinking about that too, and I find it rather hard to come up with a really good solution.
>> 
>> The desirable thing would be an enum, but such can’t be extended in Swift w/o an associated value. Like so
>> 
>>   enum HTTPMethod {
>>     case GET, REPORT, MKCALENDAR, CHECKOUT, …
>>     case ExtendedMethod(String)
>>   }
>> 
>> But I think this would be pretty weird for ‘late’ methods and you’d end up with code like
>> 
>>   switch method {
>>     case .get: ...
>>     case ExtendedMethod(“PATCH”): ...
>>   }
>> 
>> which will look really weird quickly. New methods do not come around every day, but more often than you might think (note explicit support for arbitrary ones in todays XHR, this used to support only GET/POST, hence the xhr-method header thing).
>> 
>> hh
>> 
>> _______________________________________________
>> swift-server-dev mailing list
>> swift-server-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-server-dev
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170323/ad27ca8c/attachment.html>