<p dir="ltr">Hello, Helge!</p>
<p dir="ltr">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! đ</p>
<br><div class="gmail_quote"><div dir="ltr">On Wed, Jun 14, 2017, 09:25 Helge HeĂ via swift-server-dev <<a href="mailto:swift-server-dev@swift.org">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 13:41, Rien <Rien@Balancingrock.nl> wrote:<br>
> I may be using the wrong terminology, please correct me where I am wrong.<br>
> I assume that priority assignment involves rescheduling (even cancelling) of tasks and thus also the protection of resources.<br>
<br>
Assumptions are not a good thing to base discussions on. May I kindly suggest:<br>
<br>
 <a href="https://tools.ietf.org/html/rfc7540" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc7540</a><br>
<br>
Then please formulate which parts of HTTP/2 would require what in the API or concurrency layer and why.<br>
<br>
<br>
>> HTTP/2 has the same request/response model that HTTP/1 has. To the application layer it is completely transparent and adds two main features:<br>
> What do you mean with âcompletely transparentâ?<br>
<br>
In the easy case you get a request and deliver a response which from the API perspective can be identical between HTTP/1 and 2 as the processing model is exactly the same.<br>
<br>
<br>
> I was under the impression that the application layer and possibly even the content has to know about HTTP/2 in order to fully utilize it.<br>
<br>
If you want to push resources and change the priority you obviously need API. But you donât have to do such, they are optional features.<br>
<br>
<br>
On 14 Jun 2017, at 13:34, Tanner Nelson via swift-server-dev <<a href="mailto:swift-server-dev@swift.org" target="_blank">swift-server-dev@swift.org</a>> wrote:<br>
> In terms of timing, though, is it possible to come to a consensus on an HTTP/1.1 API first and then add HTTP/2? In other words, are the features additive? Or is it pertinent HTTP/2 is a part of the design process for HTTP/1.1 support?<br>
<br>
IMO it should be considered _now_. You donât want to have two APIs when one would be sufficient.<br>
I donât have the time to make a proper proposal right now, but essentially there would need to be a change in how responses are initiated.<br>
I donât expect the change to be very complex or difficult, it just needs to be well thought through wrt supporting HTTP/1 and /2.<br>
<br>
(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.)<br>
<br>
<br>
On 14 Jun 2017, at 13:23, Michael Chiu <<a href="mailto:hatsuneyuji@icloud.com" target="_blank">hatsuneyuji@icloud.com</a>> wrote:<br>
> HTTP/2 is pretty hard to implement<br>
<br>
That was mentioned a few times in the past and I donât really understand why. I donât think it is particularly hard to implement a working HTTP/2 stack (in a way it is easier because it is a clean binary protocol w/ no legacy).<br>
If you want to implement stream priorities (which are entirely optional), you need a nice I/O scheduler, but that is not required to get started and just icing on the cake.<br>
<br>
Or you use nghttp2. Which I donât think is desirable due to the large amount of dependencies it has (didnât that use Boost and more?).<br>
<br>
<br>
And oh, BTW, my mod_swift implementation of the current API just works over HTTP/2 :-)<br>
<br>
 <a href="https://github.com/modswift/http/tree/implementation/mod_swift" rel="noreferrer" target="_blank">https://github.com/modswift/http/tree/implementation/mod_swift</a><br>
<br>
hh<br>
<br>
_______________________________________________<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/mailman/listinfo/swift-server-dev</a><br>
</blockquote></div>