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

> On 20 Jul 2015, at 17:41, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> 

Thanks for the feedback Ilari! It’s much appreciated

> The seemingly only reason server-side SETTINGS_PEER_TO_PEER
> is if client wants to wait for acknowledge of server support
> before sending its CLIENT_AUTHORITY frames. But omitting that
> wait would just cause the CLIENT_AUTHORITY frames to be harmlessly
> ignored.

That’s not the reason. The reason the server would emit SETTINGS_PEER_TO_PEER is to indicate that it’s willing to accept PUSH_PROMISE frames sent from the client. Note that this spec forbids the client from pushing streams without that setting being sent by the server.

I don’t *think* the spec is unclear here, but I’d welcome suggestions for clearer wording if you have any.


> What are the semantics if client sends multiple CLIENT_AUTHRORITY
> frames?

Good question, I’ll update the spec to cover this. The best approach seems to be to say that each CLIENT_AUTHORITY frame is the complete set of information, so any subsequent CLIENT_AUTHORITY frame overrides the information in earlier ones.

> The document seems to assume authorities are always global, not
> either global or of restricted scope (including link-local).
> But usage of authorities of restricted scope has its own issues.

Yeah, this is tricky. I’m not sure whether any guidance can be given here without making the matter even less clear.

> The descriptions of PUSH_PROMISE behavior look bit convoluted.
> 
> One seems to say that (given certain conditions) server MAY
> set SETTINGS_PUSH_PROMISE to 1.
> 
> The other seems to say that to push, one must have per-stream
> server role on associated stream.

Both things are true. In order to push a stream, the remote peer must have sent SETTINGS_PUSH_PROMISE with value 1, and also the local peer must have per-stream server role on the associated stream. Can you suggest some clearer wording for this?

Cory

Received on Tuesday, 21 July 2015 12:48:46 UTC