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

[Rien]

> On 14 Jun 2017, at 13:23, Helge Heß via swift-server-dev <swift-server-dev at swift.org> wrote:
> 
> On 14 Jun 2017, at 13:10, Rien <Rien at Balancingrock.nl> wrote:
>> According to wikipedia, market penetration is about 14% for HTTP/2 servers.
>> 
>> Though not necessarily so, it does seem to me that HTTP/2 and a native swift concurrency model might go hand in hand?
>> 
>> I.e. does it make sense to talk about HTTP/2 support without a native Swift concurrency API?
> 
> I have no idea what you are talking about. What has the concurrency model to do w/ HTTP?

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.


> 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"?
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.

Rien.

> 
> a) Server push. When receiving a request, the server can deliver
>   additional responses to the server, as if the server had
>   requested them).
>   (Note that this has nothing to do w/ ‘Push’ in the traditional
>    sense, i.e. the server cannot on its own initiate a new stream
>    and talk back to the client.)
> 
> b) Stream priorities. I think either side can assign a priority to
>   the request/response stream. That way e.g. HTML content can be
>   delivered before e.g. images.
> 
> 
> For a) we would essentially need API which allows the programmer
> to attach additional responses to a request (and only do so if the
> protocol supports so, to avoid extra work).
> I expect a) to be very useful for API endpoints too.
> 
> b) Is a little trickier (you need to perform I/O scheduling which
> e.g. GCD channels AFAIK do not support) and I suppose is not widely
> implemented. It is optional though, we can do the imp later but
> provide the API for it upfront.
> 
> hh
> 
> _______________________________________________
> swift-server-dev mailing list
> swift-server-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-server-dev