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