[swift-server-dev] Convert HTTPVersion to struct

[Chris Bailey]

Based on where we are at the moment - which is dealing with HTTPVersion as 
a separate type - it sounds like we're converging on using a struct. As 
such if there's no strong objection I'll merge the PR as-is.

That doesn't close down the conversation with respect to what we 
could/should do for HTTP/2 - just spins it off separately.

Chris


swift-server-dev-bounces at swift.org wrote on 14/06/2017 14:41:48:

> From: Michael Chiu via swift-server-dev <swift-server-dev at swift.org>
> To: Tanner Nelson <tanner at vapor.codes>
> Cc: Paulo Faria via swift-server-dev <swift-server-dev at swift.org>
> Date: 14/06/2017 15:19
> Subject: Re: [swift-server-dev] Convert HTTPVersion to struct
> Sent by: swift-server-dev-bounces at swift.org
> 
> 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
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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