Re: New Version Notification for draft-benfield-http2-p2p-01.txt

On 24/08/2015 8:33 p.m., Cory Benfield wrote:
> 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).
> 

Nit pick: if this gets anywhere near a spec make sure the example
authority names are clearly and instantly distinguishable from each
other. One digit is still quite mind-boggling.


> 
>> 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.


I think that wording you just used is probably the most clear its going
to get:

> PUSH_PROMISE frames can
> only be sent on streams that the given peer did not initiate.


Amos

Received on Monday, 24 August 2015 16:03:27 UTC