- From: Cory Benfield <cory@lukasa.co.uk>
- Date: Fri, 10 Jul 2015 09:47:27 +0100
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: Juan Benet <juan@benet.ai>, Fedor Indutny <fedor@indutny.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, daviddias@ipfs.io, Jeromy Johnson <why@ipfs.io>
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: > 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
Received on Friday, 10 July 2015 08:47:55 UTC