[swift-server-dev] Convert HTTPVersion to struct

[Tanner Nelson]

It's worth noting that HTTP/2 refers to the method header as a special
"pseudo-header".

> All HTTP/2 requests MUST include exactly one valid value for the :method,
:scheme, and :path pseudo-header fields.
https://http2.github.io/http2-spec/#rfc.section.8.1.2.3

So even though it's being passed as a "header", it's a special header
distinct from ones like content-type which could merit it continuing to be
a stored property on Request.

On Wed, Jun 14, 2017 at 2:41 PM Michael Chiu <hatsuneyuji at icloud.com> wrote:

> So are we going to write our own http parser?
>
> If not, I don’t see the benefit of ditching version and method properties
> since both major/minor version and method are given by the http_parser, and
> users are expecting to find it in the property since these components are
> well defined in RFC and guaranteed its existence in a proper http req/res.
> Hence they deserve to be an independent property.
>
> On the other hand, there’s no one guarantee the existence of Content-Type
> and Content-Length etc header exists in HTTP protocol (I can be wrong).
>
> Michael.
>
> On Jun 14, 2017, at 6:27 AM, Tanner Nelson via swift-server-dev <
> swift-server-dev at swift.org> wrote:
>
>
>
> On Wed, Jun 14, 2017 at 2:11 PM Helge Heß via swift-server-dev <
> swift-server-dev at swift.org> wrote:
>
>> On 14 Jun 2017, at 14:59, Paulo Faria <paulo at zewo.io> wrote:
>> > You're completely right we should care about HTTP 2.0 now. But let's do
>> it one step at a time, or else we won't get things done. The current topic
>> is the HTTPVersion type. So could you please give your feedback in the
>> HTTPVersion thread about how the current proposal of HTTPversion fits with
>> HTTP 2.0? We should go from lower abstractions to higher abstractions
>> incrementally but definitely considering the upper abstractions. Let's keep
>> focus and move on! 😊
>>
>> I gave my feedback on the type in the this thread already. Struct is fine
>> for me, tuple is OK too. I don’t actually care much as “The HTTP version
>> should only matter for logging purposes”. If it comes with comparison
>> operations and such, something is likely wrong with the API.
>>
>>
>> The only HTTP/2 specific note I have is this thing:
>>
>>   From the HTTPRequest API design perspective there is a small
>>   change in that method/version are just headers in HTTP/2.
>>   I brought that up before.
>>   E.g. why does ‘method' deserve a special enum, but not
>>   content-type etc which is equally important for dispatching
>>   a request. Either approach is fine though.)
>>
>
> In that case, maybe we ditch the version and method properties in favor of
> something more generic like:
>
> (just spitballing some pseudo swift here)
> ```swift
>
>     struct Request {
>         ...
>         enum Metadata {
>             case original(major: Int, minor: Int, Method)
>             case headers
>         }
>
>         var metadata: Metadata
>         ...
>     }
>
>
>     extension Request {
>         var method: Method {
>             switch metadata {
>             case .original(_, _, let method):
>                 return method
>             case .headers:
>                 return Method(rawValue: headers["Method"])
>             }
>         }
>     }
>
> ```
> Here an enum's ability to exhaustively switch would be useful. Then
> `req.method` is implemented as an extension similar to how `req.version`
> and `req.contentType` could be implemented.
>
>
>> This affects the discussion as it may make sense to expose the
>> HTTPVersion as a regular header to mirror the new HTTP/2 setup
>> instead of basing the API on the old HTTP/0,1 model.
>> (I think either is fine, with a slight preference for going
>>  with the ‘future’)
>>
>> Or in other words: Why struct or tuple, just keep it as a string
>> like the other headers.
>>
>> If HTTPVersion is not exposed as a String but as a specific type,
>> that would then affect the way headers in general are handled
>> (and I’m very much in favour of NOT using strings for the common
>>  ones for various reasons).
>>
>> 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/20170614/050a9abf/attachment.html>