Re: HTTP2 server-side stream creation

(Replying from my personal email)

Thank you for adding me to the thread. We’ve and seen and worked with several implementations of the SPDY framing layer recently, most notable are muxado[1], yamux[2] and the one we currently use on the IPFS project, spdystream[3]. One of the main reasons behind these efforts is due to the fact that SPDY offers a spec for a stream multiplexing with back pressure and flow control, including priority mechanisms, which makes it extremely interesting  for cross compatibility between several implementations in different languages.

Currently, with have cross compatibility with spdystream (Docker’s Go implementation) and spdy-transport (Fedor’s Node.js implementation) working, both respecting the SPDY framing layer specification, which suits the purpose and as long as the listener is also able to ‘request’ a new stream to open from the ‘dialer', of course, other than a push stream. SPDY, or the HTTP2 framing layer, have a great use case for applications that need a great amount and several types of data to flow.

Right now this solutions exist due to the understanding that the SPDY framing layer can be mounted as a stand alone stream muxer, but if there is a way to make it official that there is a great use case and benefit of having it as its own extension to the protocol, we, Protocol Labs (http://ipn.io/ <http://ipn.io/>), would love to contribute.

Thank you, 

[1] - https://github.com/inconshreveable/muxado <https://github.com/inconshreveable/muxado>
[2] - https://github.com/hashicorp/yamux <https://github.com/hashicorp/yamux>
[3] - https://github.com/docker/spdystream <https://github.com/docker/spdystream>



David Dias
@daviddias <https://twitter.com/daviddias>

> ----------- Forwarded message -----------
> From: fedor@indutny.com <mailto:fedor@indutny.com>
> Date: Wed Jul 08 2015 01:18:32 GMT-0700 (PDT)
> Subject: Re: HTTP2 server-side stream creation
> To: cory@lukasa.co.uk <mailto:cory@lukasa.co.uk>
> Cc: ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>, contact@liftsecurity.io <mailto:contact@liftsecurity.io>
> 
> 
>> +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>
>>