[swift-server-dev] Stream priorities & push in HTTPResponse
Helge Heß
me at helgehess.eu
Wed Jun 14 06:23:34 CDT 2017
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?
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:
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
-------------- 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/13799d0e/attachment.sig>
More information about the swift-server-dev
mailing list