search

httpwg / httpbis-issues

1 stars 1 forks source link

Ordering in Upgrade #445

Closed mnot closed 4 years ago

mnot commented 11 years ago

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.

Reported by @mnot, migrated from https://trac.ietf.org/trac/httpbis/ticket/445

mnot commented 11 years ago

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 commented 11 years ago

@mnot commented:

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 commented 11 years ago

@mnot commented:

Also, make "descending" explicit

mnot commented 11 years ago

fielding@gbiv.com commented:

From 2274:

Define ordering for Upgrade; addresses #445

mnot commented 11 years ago

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.

mnot commented 11 years ago

julian.reschke@gmx.de commented:

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

mnot commented 11 years ago

julian.reschke@gmx.de commented:

From 2275:

record change (see #445)

mnot commented 11 years ago

julian.reschke@gmx.de commented:

From 2311:

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

mnot commented 11 years ago
mnot commented 11 years ago