Re: HTTP2 server-side stream creation

On 10/07/2015 8:47 p.m., Cory Benfield wrote:
> On 10 July 2015 at 09:13, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>> 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?
> 
> I think this is the critical question to answer. I think the server
> can assume that the client would answer incoming HTTP requests, but we
> definitely have to decide how to signal the client authority.
> 
> This cannot be negotiated in the SETTINGS frame because with only 32
> bits available for the settings value a client would be pretty limited
> in what it can offer. That really leaves us with either using a HTTP
> header field, piggybacking on a different frame type, or introducing a
> new frame type. I think using a header field for this is a bit
> unpleasant (it smacks of the weirdness of Reverse HTTP[0] which I
> don't particularly love), though it could work. I don't think there's
> a good frame type to piggyback on, so the other option would be to
> have a new frame type that is used in this case. That feels like the
> best option: the client essentially emits a frame that says "I am
> happy to receive requests for authority X".
> 
>> 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?
> 
> Yeah, this is a good question. I think it depends on what kind of
> extension NTP is.
> 
> Extensions like HTTP/2 Encoded Data[1], which advertise a capability
> possessed by one of the peers, are unaffected by HTTP/2 P2P. If the
> client advertises SETTINGS_ACCEPT_GZIPPED_DATA and
> SETTINGS_PEER_TO_PEER, the server may send a request to the client and
> use a GZIPPED_DATA frame in the body of that request.
> 
> For types of extensions like Alt Svc[2], which talk about 'client' and
> 'server', the terms vary on a stream-by-stream basis. That means that
> if the server peer sends a request to the client in a HTTP/2 P2P
> dialog, the client may emit an ALTSVC frame if it so chooses (because
> it's technically the server for that stream).
> 
> The other type of extension that might exist is one that applies to
> the connection as a whole, rather than to individual streams.

> Currently Section 2.3. says that both peers should be considered both
> servers and clients, but I'm now thinking that that's a bad idea. How
> about the following:

I agree on that being a bad idea. But disagree on your proposed solution...

> 
>> When this extension is deployed with other extensions to HTTP/2, the
>> behaviour of this extension does not change. All other extensions
>> that refer to 'client' or 'server' MUST be treated as though those
>> terms apply on a per-stream basis.
>>
>> For stream 0, the connecting peer is the 'client', and the accepting peer
>> is the 'server'.
>>
>> If a setting is defined as valid only for servers or only for clients (e.g.
>> SETTINGS_ENABLE_PUSH can only be sent by clients), the peer that
>> could not normally emit that setting MAY emit it after HTTP/2 P2P has
>> been negotiated. Before HTTP/2 P2P has been negotiated, peers MUST
>> NOT emit a setting they could not normally emit.
> 
> How does that seem?

I think this extension should mean only that the sender (normally
client) is agreeing to be a server in the context of this whole
connection. The recipient may then perform stream initiation as per the
specifiation for how clients initiate streams to a server.

Streams initiated by either end must still conform to the Stream-ID
allocation behaviour defined for clients and servers. ID selection is
already relative to the emitters placement as client or server (even or
odd numbering). All this extension need do is make the connection
endpoints agree that client/server placement may change per-stream
depending on stream initiator.


Implicitly the initiator of the whole connection is the client by
default and can assume that the other end is a server. Any such flag
coming back from a "real" server on the connection is either not useful,
or equivalent to an ACK for the extension.

A real server that does not support the extension will not initiate
streams to the client other than perhapse PUSH_PROMISE. Thus there is no
actual need to ack the extension. Just dropping it as unknown is a fine
way to disable.


> 
> [0]: http://tools.ietf.org/html/draft-lentczner-rhttp-00
> [1]: https://datatracker.ietf.org/doc/draft-kerwin-http2-encoded-data/
> [2]: https://datatracker.ietf.org/doc/draft-ietf-httpbis-alt-svc
> 


Amos

Received on Friday, 10 July 2015 12:07:45 UTC