RE: HTTP2 server-side stream creation

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:squid3@treenet.co.nz] 
Sent: Wednesday, July 8, 2015 3:30 AM
To: ietf-http-wg@w3.org
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

Received on Wednesday, 8 July 2015 17:50:55 UTC