[swift-server-dev] Stream priorities & push in HTTPResponse
Rien
Rien at Balancingrock.nl
Wed Jun 14 06:41:58 CDT 2017
> 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
More information about the swift-server-dev
mailing list