- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Sun, 12 Jul 2015 11:09:34 +0100
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> On 11 Jul 2015, at 09:04, Stefan Eissing <stefan.eissing@greenbytes.de> wrote: > > When I first asked people here about server-side streams, the proposed mechanism was that the client opens a "send me push promises on this one and no answer" stream. > > Such special streams that do not expect a reply would be suitable to announce service endpoints. > > Assume the client wants to serve http. It opens a stream X with special flag and a header like ":service http". The server then opens a stream Y to this service by a push promise on X. > > If the client no longer wants to serve http, it RST_STREAMS X. > > This should make it easy for intermediaries to make informed decisions about routing such streams or even announcing services themselves. > > //stefan > I don’t think this model works quite right. The semantic of PUSH_PROMISE is that the server provides both the request and its response. This does not allow the client to serve HTTP because it does not allow the client to generate its responses itself. This model allows for a non-HTTP bi-directional communication stream, but does not move to a fully P2P solution.
Received on Sunday, 12 July 2015 10:09:59 UTC