<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">So are we going to write our own http parser?</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">Michael.</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 14, 2017, at 6:27 AM, Tanner Nelson via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jun 14, 2017 at 2:11 PM Helge Heß via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a>> wrote:<br class=""></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" class="">paulo@zewo.io</a>> wrote:<br class="">
> 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 class="">
<br class="">
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 class="">
<br class="">
<br class="">
The only HTTP/2 specific note I have is this thing:<br class="">
<br class="">
From the HTTPRequest API design perspective there is a small<br class="">
change in that method/version are just headers in HTTP/2.<br class="">
I brought that up before.<br class="">
E.g. why does ‘method' deserve a special enum, but not<br class="">
content-type etc which is equally important for dispatching<br class="">
a request. Either approach is fine though.)<br class=""></blockquote><div class=""><br class=""></div><div class="">In that case, maybe we ditch the version and method properties in favor of something more generic like:</div><div class=""><br class=""></div><div class="">(just spitballing some pseudo swift here)</div><div class="">```swift</div><div class=""><br class=""></div><div class=""><div class=""> struct Request {</div><div class=""> ...</div><div class=""> enum Metadata {</div><div class=""> case original(major: Int, minor: Int, Method)</div><div class=""> case headers</div><div class=""> }</div><div class=""><br class=""></div><div class=""> var metadata: Metadata</div><div class=""> ...</div><div class=""> }</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> extension Request {</div><div class=""> var method: Method {</div><div class=""> switch metadata {</div><div class=""> case .original(_, _, let method):</div><div class=""> return method</div><div class=""> case .headers:</div><div class=""> return Method(rawValue: headers["Method"])</div><div class=""> }</div><div class=""> }</div><div class=""> }</div></div><div class=""><br class=""></div><div class="">```</div><div class="">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 class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="">
This affects the discussion as it may make sense to expose the<br class="">
HTTPVersion as a regular header to mirror the new HTTP/2 setup<br class="">
instead of basing the API on the old HTTP/0,1 model.<br class="">
(I think either is fine, with a slight preference for going<br class="">
with the ‘future’)<br class="">
<br class="">
Or in other words: Why struct or tuple, just keep it as a string<br class="">
like the other headers.<br class="">
<br class="">
If HTTPVersion is not exposed as a String but as a specific type,<br class="">
that would then affect the way headers in general are handled<br class="">
(and I’m very much in favour of NOT using strings for the common<br class="">
ones for various reasons).<br class="">
<br class="">
hh<br class="">
<br class="">
_______________________________________________<br class="">
swift-server-dev mailing list<br class="">
<a href="mailto:swift-server-dev@swift.org" target="_blank" class="">swift-server-dev@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">swift-server-dev mailing list<br class=""><a href="mailto:swift-server-dev@swift.org" class="">swift-server-dev@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-server-dev" class="">https://lists.swift.org/mailman/listinfo/swift-server-dev</a><br class=""></div></blockquote></div><br class=""></div></div></body></html>