W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2015

Re: HTTP2 server-side stream creation

From: Cory Benfield <cory@lukasa.co.uk>
Date: Wed, 8 Jul 2015 08:49:46 +0100
Message-ID: <CAH_hAJE+9Y5rZeHPHNpDYW6p4jQEC1yN5C3Jd96M-YiZrY0mFw@mail.gmail.com>
To: Fedor Indutny <fedor@indutny.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 7 July 2015 at 23:43, Fedor Indutny <fedor@indutny.com> wrote:
> Obviously, the most straightforward way is to do a PUSH_PROMISE on
> existing client-initiated stream, but it appears to me that the
> server-initiated streams created using HEADERS frame are valid
> too.

>From section 8.1 of RFC 7540[0]:

> A client sends an HTTP request on a new stream, using a previously
> unused stream identifier (Section 5.1.1).  A server sends an HTTP
> response on the same stream as the request.

My reading is that this forbids a 'server' from sending a HEADERS
frame first, because servers send responses on already-opened streams.

You could pretty easily construct a semantic for this that essentially
turns HTTP/2 into a peer-to-peer communication stream, with both sides
of the connection being free to issue requests. This could plausibly
be very valuable in systems that use HTTP/2 as an RPC transport. I
suspect most clients will currently not allow that behaviour, however,
so if you wanted it it might be best to propose it as a negotiated
HTTP/2 extension, per section 5.5 of RFC 7540[1]. If you (or anyone
else on the list) think this is interesting I'd be happy to co-author
a draft to propose it.


[0]: https://tools.ietf.org/html/rfc7540#section-8.1
[1]: https://tools.ietf.org/html/rfc7540#section-5.5
Received on Wednesday, 8 July 2015 07:50:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:45 UTC