- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Mon, 13 Jul 2015 10:07:58 +0200
- To: Cory Benfield <cory@lukasa.co.uk>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> Am 12.07.2015 um 12:09 schrieb Cory Benfield <cory@lukasa.co.uk>: > >> >> On 11 Jul 2015, at 09:04, Stefan Eissing <stefan.eissing@greenbytes.de> wrote: >> ... >> 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. Yeah, you probably rigtht. It might bend the normal http/2 model more than necessary. So, the issue remains with server-initiated streams to define what they exactly connect against. In the case of special data backend server connections, this might be clear by the configuration of it, so outside of protocol context. And for that it is useful, no doubt. For it to work in the wild net, something is missing, I think. //Stefan <green/>bytes GmbH Hafenweg 16, 48155 Münster, Germany Phone: +49 251 2807760. Amtsgericht Münster: HRB5782
Received on Monday, 13 July 2015 08:08:27 UTC