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

[Helge Heß]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-server-dev/attachments/20170614/c38e0785/attachment.sig>