- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Wed, 8 Jul 2015 17:50:27 +0000
- To: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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