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

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Apr 2013 14:07:57 +1000

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.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 20 Apr 2013 09:10:42 +0200

On Sat, Apr 20, 2013 at 02:07:57PM +1000, Mark Nottingham wrote:
> 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.

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Apr 2013 17:13:09 +1000

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

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 20 Apr 2013 09:17:36 +0200

On Sat, Apr 20, 2013 at 05:13:09PM +1000, Mark Nottingham wrote:
> 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.

OK so your suggestion makes pretty much sense then, we could probably state
that servers should pick the first one they support and that clients supporting
multiple protocols order them by preference ?

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 20 Apr 2013 17:52:00 +1000

Recorded as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/445>.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Apr 2013 17:38:59 +1000

Proposal - add to p1 6.7:

"""
When occurring in a request, Upgrade's value indicate the protocol(s) the client would like to upgrade to, in order of relative preference. When occurring in a 101 (Switching Protocols) response, there will usually only be one protocol indicated in Upgrade. When occurring in any other response, Upgrade indicates the protocol(s) the server is capable of upgrading to, in order of relative preference.
"""

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 23 Apr 2013 10:12:09 +0200

Hi Mark,

On Tue, Apr 23, 2013 at 05:38:59PM +1000, Mark Nottingham wrote:
> When occurring in a request, Upgrade's value indicate the protocol(s) the
> client would like to upgrade to, in order of relative preference. When
> occurring in a 101 (Switching Protocols) response, there will usually only be
> one protocol indicated in Upgrade. When occurring in any other response,
> Upgrade indicates the protocol(s) the server is capable of upgrading to, in
> order of relative preference.
> """

I'm OK in the principle, though I think this should be fused into existing
text, probably that way :

   The "Upgrade" header field is intended to provide a simple mechanism
   for transitioning from HTTP/1.1 to some other protocol on the same
   connection.  A client MAY send a list of protocols in order of relative
   preference in the Upgrade header field of a request to invite the server
   to switch to one or more of those protocols before sending the final
   response.  A server MUST send an Upgrade header field in 101 (Switching
   Protocols) responses to indicate which protocol(s) are being switched
   to, and MUST send it in 426 (Upgrade Required) responses to indicate
   acceptable protocols in order of relative preference.  A server MAY
   send an Upgrade header field in any other response to indicate that
   they might be willing to upgrade to one of the specified protocols for
   a future request, in order of relative preference.

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Apr 2013 18:14:49 +1000

WFM

---

From: Roberto Peon <[email-masked]>
Date: Tue, 23 Apr 2013 02:24:47 -0700

A complication here is that it isn't sufficient to state the protocol as
HTTP/2
As an example assuming we may wish to use the version that negotiates using
ALPN over TLS/:443, we'd be unhappy unless we become more specific about
what the various version strings for (at least) HTTP/2 will mean in this
field.

In alternate-protocol, this was dealt with by having different version
strings for the possibly different negotiation mechanisms (though nothing
but NPN was really used), e.g.
npn-http/2 vs http/2 or, more completely, 443:npn-http/2 or 80:http/2

-=R

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 23 Apr 2013 19:35:21 +1000

On 23/04/2013, at 7:24 PM, Roberto Peon <[email-masked]> wrote:

> A complication here is that it isn't sufficient to state the protocol as HTTP/2
> As an example assuming we may wish to use the version that negotiates using ALPN over TLS/:443, we'd be unhappy unless we become more specific about what the various version strings for (at least) HTTP/2 will mean in this field.

I think that's the plan...

> In alternate-protocol, this was dealt with by having different version strings for the possibly different negotiation mechanisms (though nothing but NPN was really used), e.g.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 23 Apr 2013 02:46:23 -0700

Excellent. Almost at the point of not needing alternate-protocol. :)

The last difference here is that alternate-protocol allows the client to
cache this data, so that it may negotiate the new protocol (on some future
connection) potentially without being forced to do an upgrade.

Today, this mainly is interesting for resources with an http scheme being
served over an encrypted channel where the upgrade isn't necessary. With
the value in the upgrade field cached, the browser can see an http scheme
for that origin and immediately make an ALPN-negotiated connection

-=R

On Tue, Apr 23, 2013 at 2:35 AM, Mark Nottingham <[email-masked]> wrote:

> > As an example assuming we may wish to use the version that negotiates
> using ALPN over TLS/:443, we'd be unhappy unless we become more specific
> about what the various version strings for (at least) HTTP/2 will mean in
> this field.
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 23 Apr 2013 10:16:25 -0700

I think adding the relative preference semantic is good.

I have to confess I was not aware of using Upgrade as a response header
outside of a 101 or 426 response. This indeed sounds very similar to
Alternate-Protocol. Is anyone actually using this in practice?

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 23 Apr 2013 19:19:17 +0200

> Alternate-Protocol. Is anyone actually using this in practice?

I don't think so, since Upgrade really started to be used with WebSocket.
However RFC2817 clearly mentions this possibility without speaking about
ordering, just about combinations.

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Apr 2013 08:15:47 +1000

Keep in mind that Upgrade on a non-101 response is about advertising the possibility to upgrade *this* connection, whereas Alternate-Protocol is about advertising the potential to upgrade by switching connections.

On 24/04/2013, at 3:16 AM, William Chan (陈智昌) <[email-masked]> wrote:

> I have to confess I was not aware of using Upgrade as a response header outside of a 101 or 426 response. This indeed sounds very similar to Alternate-Protocol. Is anyone actually using this in practice?
> 
> 
> The last difference here is that alternate-protocol allows the client to cache this data, so that it may negotiate the new protocol (on some future connection) potentially without being forced to do an upgrade.
> 
> Today, this mainly is interesting for resources with an http scheme being served over an encrypted channel where the upgrade isn't necessary. With the value in the upgrade field cached, the browser can see an http scheme for that origin and immediately make an ALPN-negotiated connection 
> 
> -=R
> 
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 23 Apr 2013 17:30:41 -0700

That's an important semantic difference, thanks for highlighting it. If
that's the case, then returning a token like 443:tls-alpn-http/2 makes no
sense, since that would be on a separate connection, right? I think if
we're solely speaking about this connection, then a naked HTTP/2 string is
sufficient (and if you wanted to do StartTLS, you could use a different
string).

On Tue, Apr 23, 2013 at 3:15 PM, Mark Nottingham <[email-masked]> wrote:

> Keep in mind that Upgrade on a non-101 response is about advertising the
> possibility to upgrade *this* connection, whereas Alternate-Protocol is
> about advertising the potential to upgrade by switching connections.
>
>
> > Today, this mainly is interesting for resources with an http scheme
> being served over an encrypted channel where the upgrade isn't necessary.
> With the value in the upgrade field cached, the browser can see an http
> scheme for that origin and immediately make an ALPN-negotiated connection
> >
> > -=R
> >
> >

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 30 Apr 2013 13:20:14 +1000

I'm going to mark this resoution for incorporation into -23.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 30 Apr 2013 07:43:30 +0200

> I'm going to mark this resoution for incorporation into -23.

OK, then fixing a typo in my own text below :

- they might be willing to upgrade to one of the specified protocols for
+ it might be willing to upgrade to one of the specified protocols for

Willy