Re: HTTP2 server-side stream creation

> Am 09.07.2015 um 19:32 schrieb Cory Benfield <cory@lukasa.co.uk>:
>> It may also be less work simply extract the HTTP/2 Framing (Section
>> 5) and make a symmetric framing muxer based on it. Implementation 
>> libraries could then optionally expose the Framing part as a protocol
>> that layers, or not.
> 
> Right now I think we should pursue the relative simplicity of a negotiated extension. We may find that it’s a bit painful to think of this as HTTP/2 in P2P mode, in which case we can revisit whether this needs to be standardised in a different way.

I like extending h2 this way. Not sure about the scope yet.

What would be the minimal behavior a conforming endpoint needs to exhibit? Say a client talks h2 with just this extension. Is there anything the server can assume about the nature of the streams it can open against the client? Does the client need to answer incoming HTTP requests? Against which authority? If left unspecified, how is this extension then used?

Assuming a client would want to implement a "HTTP server" in its side, this would then be an additional extensions with its own settings? That setting would then imply the exact same spec clarifications that this generic one does? How is peer-to-peer then used?

Let's say there are two extensions "HTTP" and "NTP". "HTTP = 1" is implied in RFC 7540 for the server endpoint. Client announces "NTP = 1" in its SETTINGS. Both enable SETTINGS_PEER_TO_PEER. What is the impact?

If I read 2.3, the "server" now needs to expose some sort of behavior to the NTP extension. Basically both endpoints somehow need to mirror each other?

I *do* see the value of the spec in describing "if you do an extension that let's servers open streams to clients, this is what the changes in protocol behavior must conform to". 

Cheers,

  Stefan


<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

Received on Friday, 10 July 2015 08:13:55 UTC