Re: HTTP2 server-side stream creation

Greetings,

I'm responding too, as I helped trigger the question :).

Cory, that sounds great! In particular, the peer-to-peer use case is an 
important one. There are many systems which do not have a clear 
distinction between a "server" and "client", all "peers" merely have to 
adopt one of those roles because protocols force it (QUIC has a similar
story). It's usually fine, but the roles and limitations can force additional
complexity.

What do you think of these sections of RFC 7540 ?

From Section 5 [0]:
>  o  Streams can be established and used unilaterally or shared by
>      either the client or server.
> ...
>  o  Streams are identified by an integer.  Stream identifiers are
>      assigned to streams by the endpoint initiating the stream.

From Section 5.1 [1]:
> Both endpoints have a subjective view of the state of a stream that
> could be different when frames are in transit.  Endpoints do not
> coordinate the creation of streams; they are created unilaterally by
> either endpoint. 
>
> ...
>
> idle:
> ...
>   * Sending or receiving a HEADERS frame causes the stream to
>      become "open".  The stream identifier is selected as described
>      in Section 5.1.1.  The same HEADERS frame can also cause a
>      stream to immediately become "half-closed".

From the above, it seems to me that the spec already defines this
(servers opening regular streams) as valid. This may be a holdover 
from SPDY's clear separation between the Framing (Sec2), and the 
"layering of HTTP over SPDY" (Sec3), which scopes all the HTTP-
specific rules). It does indeed seem a bit inconsistent with our 
Section 8 [2].

I think the separation of concerns was a useful one. Though maybe
it does not belong in the HTTP/2 spec given the traditional client-
server model -- it could very well be a negotiated extension as Cory
suggests.

It may also be less work simply extract the HTTP/2 Framing (Section
5) and make a symmetric framing muxer based on it. Implementation 
libraries could then optionally expose the Framing part as a protocol
that layers, or not.

Either way, whatever seems the best route, David and I are here to
help! :)

Thanks,
Juan


[0]: https://tools.ietf.org/html/rfc7540#section-5 <https://tools.ietf.org/html/rfc7540#section-5>
[1]: https://tools.ietf.org/html/rfc7540#section-5.1 <https://tools.ietf.org/html/rfc7540#section-5.1>
[2]: https://tools.ietf.org/html/rfc7540#section-8 <https://tools.ietf.org/html/rfc7540#section-8>

On Wed, 08 Jul 2015 19:58:31, David Dias <daviddias@ipfs.io <mailto:daviddias@ipfs.io>> wrote:

(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/> <http://ipn.io/ <http://ipn.io/>>), would love to contribute.
Thank you, 
[1] - https://github.com/inconshreveable/muxado <https://github.com/inconshreveable/muxado> <https://github.com/inconshreveable/muxado <https://github.com/inconshreveable/muxado>>
[2] - https://github.com/hashicorp/yamux <https://github.com/hashicorp/yamux> <https://github.com/hashicorp/yamux <https://github.com/hashicorp/yamux>>
[3] - https://github.com/docker/spdystream <https://github.com/docker/spdystream> <https://github.com/docker/spdystream <https://github.com/docker/spdystream>>


David Dias
@daviddias <https://twitter.com/daviddias <https://twitter.com/daviddias>>
> ----------- Forwarded message -----------
> From: fedor@indutny.com <mailto:fedor@indutny.com> <mailto: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> <mailto:cory@lukasa.co.uk <mailto:cory@lukasa.co.uk>>
> Cc: ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org> <mailto:ietf-http-wg@w3.org <mailto:ietf-http-wg@w3.org>>, contact@liftsecurity.io <mailto:contact@liftsecurity.io> <mailto: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> <mailto: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> <mailto: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> <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> <https://tools.ietf.org/html/rfc7540#section-5.5 <https://tools.ietf.org/html/rfc7540#section-5.5>>