Re: HTTP2 server-side stream creation

[Cory Benfield <[e-mail]>]

On 10 July 2015 at 09:13, Stefan Eissing <[e-mail]> 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:

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

[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