[swift-server-dev] Stream priorities & push in HTTPResponse

[Paulo Faria]

Hello, Helge!

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! 😊

On Wed, Jun 14, 2017, 09:25 Helge Heß via swift-server-dev <
swift-server-dev at swift.org> wrote:

> On 14 Jun 2017, at 13:41, Rien <Rien at Balancingrock.nl> wrote:
> > I may be using the wrong terminology, please correct me where I am wrong.
> > I assume that priority assignment involves rescheduling (even
> cancelling) of tasks and thus also the protection of resources.
>
> Assumptions are not a good thing to base discussions on. May I kindly
> suggest:
>
>   https://tools.ietf.org/html/rfc7540
>
> Then please formulate which parts of HTTP/2 would require what in the API
> or concurrency layer and why.
>
>
> >> 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:
> > What do you mean with “completely transparent”?
>
> 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.
>
>
> > 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.
>
> 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.
>
>
> On 14 Jun 2017, at 13:34, Tanner Nelson via swift-server-dev <
> swift-server-dev at swift.org> wrote:
> > 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?
>
> IMO it should be considered _now_. You don’t want to have two APIs when
> one would be sufficient.
> 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.
> 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.
>
> (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.)
>
>
> On 14 Jun 2017, at 13:23, Michael Chiu <hatsuneyuji at icloud.com> wrote:
> > HTTP/2 is pretty hard to implement
>
> 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).
> 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.
>
> 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?).
>
>
> And oh, BTW, my mod_swift implementation of the current API just works
> over HTTP/2 :-)
>
>   https://github.com/modswift/http/tree/implementation/mod_swift
>
> hh
>
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170614/de4f6a8d/attachment.html>