Ordering in Upgrade

[mnot@…]

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.

[mnot@…]

Proposal from list:

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.

[mnot@…]

Rewording from list:

I suggest the following change, since otherwise it could be understood that the server may return the protocols in any order instead of in order of relative preference in a 101 response:

"A server MUST send an Upgrade header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched to, in order of relative preference, and MUST send it in 426 (Upgrade Required) responses [etc]."

[mnot@…]

Also, make "descending" explicit

[fielding@…]

From [2274]:

Define ordering for Upgrade; addresses #445

[fielding@…]

A client can now express an ordering preference, but Upgrade was previously defined to allow the server to select whichever order is best. In general, servers know far better than clients which protocol is best due to the varying nature of services.

[julian.reschke@…]

Do we need to record this in the changes-from-rfc2616 section?

[julian.reschke@…]

From [2275]:

record change (see #445)

[julian.reschke@…]

From [2311]:

mention ordering field value significance change in changes section (see #445)