- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Mon, 24 Aug 2015 09:33:26 +0100
- To: David Dias <daviddias@ipfs.io>
- Cc: Fedor Indutny <fedor@indutny.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, Glen Knowles <gknowles@ieee.org>, Juan Benet <juan@benet.ai>
On 23 August 2015 at 15:27, David Dias <daviddias@ipfs.io> wrote: > Does this mean that a HTTP2-P2P client would have to announce every single > authority it is willing to accept requests from? Nope, you have this backward. The client announces what authorities it believes *it is*. This is necessary because the server (turned client) needs to know what authority it is requesting data from (at the very least to populate the :authority pseudo-header field) when it makes requests. The flow is as follows: Client initiates connection to 'h2peer.com', and offers H2 P2P. It emits a CLIENT_AUTHORITY frame indicating that the client believes it is authority 'h2peer2.com' Server verifies the client's IP address against a static list to confirm that the client actually is 'h2peer2.com' Client can now make HTTP requests to the server (authority h2peer.com) and the server can make requests to the client (authority h2peer2.com). > I believe the intended behaviour would be for a server to be able to send a > PUSH_PROMISE frame on a client-initiated stream (a first request from the > client) and not on a server-initiate stream. I think this represents a problem with the ambiguity of 'client' and 'server'. This should really be saying that PUSH_PROMISE frames can only be sent on streams that the given peer did not initiate. I'll attempt to reword with 'dialer' and 'listener' (or something similar) to avoid the ambiguity. Cory
Received on Monday, 24 August 2015 08:33:56 UTC