Re: HTTP2 server-side stream creation

[Cory Benfield <[e-mail]>]

With the IETF Prague meeting so close I currently cannot submit any internet drafts, but in the meantime a quick top-level proposal is readable here[0] if anyone would like to provide feedback.

I’ll submit the ID properly when submissions re-open on the 19th.

Cory

[0]: https://raw.githubusercontent.com/Lukasa/http2-p2p/master/draft-benfield-http2-p2p-00.txt

> On 8 Jul 2015, at 18:50, Mike Bishop <[e-mail]> wrote:
> 
> Alternately stated, HTTP/2 defines two "things" -- a multiplexed binary framing layer, and a mapping of HTTP semantics to that framing layer.
> 
> The framing layer doesn't prohibit server-initiated streams, but outside of Server Push the mapping of HTTP semantics doesn't use them.  A server-initiated stream wouldn't mean anything to an HTTP client, until you have an extension that defines them.
> 
> -----Original Message-----
> From: Amos Jeffries [mailto:[e-mail]] 
> Sent: Wednesday, July 8, 2015 3:30 AM
> To: [e-mail]
> Subject: Re: HTTP2 server-side stream creation
> 
> On 8/07/2015 7:49 p.m., Cory Benfield wrote:
>> On 7 July 2015 at 23:43, Fedor Indutny 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.
> 
> Technically.
> 
> However, HTTP/1.x currently still exists in the world. A surprisingly large number of connections one way or another pass over at least one HTTP/1.x transit hop. So for now any implementations will have to cope with translation to HTTP/1.x where server requests are not possible.
> 
> HTTP/2 was designed with that in mind, thus it does not define server-initiated semantics. But also does not forbid them outright, since extensions or HTTP/3 may one day have a need to define it.
> 
> If you have a strong use case for it I suggest writing up a SETTINGS extension which can be negotiated between two endpoints. That way 2->1.1 gateway devices can negotiate its absence for the 1.1 hops and things still work.
> 
> HTH
> Amos
> 
>