Re: HTTP2 server-side stream creation

+David Dias

Thank you very much for a detailed response, Cory!

I think it might be very useful for communication with docker
containers, and as far as I know it was one of the applications of
SPDY protocol for David.

David,

Maybe you have something to add here?

Thank you!

On Wed, Jul 8, 2015 at 12:49 AM, Cory Benfield <cory@lukasa.co.uk <mailto:cory@lukasa.co.uk>> wrote:
On 7 July 2015 at 23:43, Fedor Indutny <fedor@indutny.com <mailto: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.

Cory

[0]: https://tools.ietf.org/html/rfc7540#section-8.1 <https://tools.ietf.org/html/rfc7540#section-8.1>
[1]: https://tools.ietf.org/html/rfc7540#section-5.5 <https://tools.ietf.org/html/rfc7540#section-5.5>