W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: p1: Upgrade ordering (possible HTTP/2 impact)

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 20 Apr 2013 17:13:09 +1000
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-Id: <77849350-125C-4F36-8D78-0FF86DA0044E@mnot.net>
To: Willy Tarreau <w@1wt.eu>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:12 UTC