- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 20 Apr 2013 17:13:09 +1000
- To: Willy Tarreau <w@1wt.eu>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 20/04/2013, at 5:10 PM, Willy Tarreau <w@1wt.eu> wrote: > On Sat, Apr 20, 2013 at 02:07:57PM +1000, Mark Nottingham wrote: >> p1 section 6.7 defines the Upgrade header, but no where does it say anything >> about relative preference. >> >> Should we define (or at least allow) for the ordering to be semantically >> significant? It seems to me that if we end up using this, and there are a few >> different variants of HTTP/2 (e.g., "normal" vs "mobile"), it'd be nice to >> rely on ordering here. > > Indeed it could be quite useful! RFC2817 does not suggest anything concerning > multiple values in the Upgrade header field for the request message, it only > suggests that the response describes the protocol stack (eg: TLS/1.0, HTTP/1.1). > > So I'm wondering if it would not be a abit awkward to have a different > definition of this header field depending on the direction. Some more thinking > is needed on this I suppose. We're already there; in the current form, it describes the protocols the client can upgrade to in requests, whereas in 101 responses it describes the (single) protocol the server *is* upgrading to. -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 20 April 2013 07:13:35 UTC