<div dir="ltr">Having the HTTPVersion as a struct allows it to be serialized in the request/response line in HTTP 1.1 and in the headers section in HTTP 2.0 with no problems. I don't see a problem with the current implementation for HTTP 2.0.<div><br></div><div><pre class="gmail-newpage" style="font-size:13.333333015441895px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">GET / HTTP/1.1
Host: <a href="http://server.example.com">server.example.com</a>
Connection: Upgrade, HTTP2-Settings
Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload></pre></div><div><br></div><div><pre class="gmail-newpage" style="font-size:13.333333015441895px;margin-top:0px;margin-bottom:0px;color:rgb(0,0,0)">HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c</pre></div><div><br></div><div>this is an upgrade from HTTP 1.1 to HTTP 2.0.. the first request and response are HTTP 1.1 requests where the version goes in the request/response line. The upgrade headers are an entirely different issue.</div><div><br></div><div>If we're not upgrading and creating an HTTP 2.0 request directly. The version of the HTTPRequest type will be used to serialize the type accordingly. How you're going to use that info is not directly related to where it will be stored or how it will be serialized. It's just a piece of information that's important for that type. Therefore I don't see an issue with the current implementation when it comes to HTTP 2.0.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 June 2017 at 10:27, Tanner Nelson via swift-server-dev <span dir="ltr"><<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span class=""><div dir="ltr">On Wed, Jun 14, 2017 at 2:11 PM Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 14 Jun 2017, at 14:59, Paulo Faria <<a href="mailto:paulo@zewo.io" target="_blank">paulo@zewo.io</a>> wrote:<br>
> 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! 😊<br>
<br>
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.<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.)<br></blockquote><div><br></div></span><div>In that case, maybe we ditch the version and method properties in favor of something more generic like:</div><div><br></div><div>(just spitballing some pseudo swift here)</div><div>```swift</div><div><br></div><div><div> struct Request {</div><div> ...</div><div> enum Metadata {</div><div> case original(major: Int, minor: Int, Method)</div><div> case headers</div><div> }</div><div><br></div><div> var metadata: Metadata</div><div> ...</div><div> }</div><div><br></div><div><br></div><div> extension Request {</div><div> var method: Method {</div><div> switch metadata {</div><div> case .original(_, _, let method):</div><div> return method</div><div> case .headers:</div><div> return Method(rawValue: headers["Method"])</div><div> }</div><div> }</div><div> }</div></div><div><br></div><div>```</div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<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></span><span class="">
______________________________<wbr>_________________<br>
swift-server-dev mailing list<br>
<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-server-<wbr>dev</a><br>
</span></blockquote></div></div>
<br>______________________________<wbr>_________________<br>
swift-server-dev mailing list<br>
<a href="mailto:swift-server-dev@swift.org">swift-server-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-server-<wbr>dev</a><br>
<br></blockquote></div><br></div>