Opened 6 years ago

Closed 6 years ago

#445 closed design (fixed)

Ordering in Upgrade

Reported by: mnot@… Owned by: draft-ietf-httpbis-p1-messaging@…
Priority: normal Milestone: 23
Component: p1-messaging Severity: In WG Last Call
Keywords: Cc:

Description

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.

Change History (10)

comment:1 Changed 6 years ago by mnot@…

  • Milestone changed from unassigned to 23

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.

comment:2 Changed 6 years ago by 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]."

comment:3 Changed 6 years ago by mnot@…

Also, make "descending" explicit

comment:4 Changed 6 years ago by fielding@…

From [2274]:

Define ordering for Upgrade; addresses #445

comment:5 Changed 6 years ago by fielding@…

  • Resolution set to incorporated
  • Status changed from new to closed

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.

comment:6 Changed 6 years ago by julian.reschke@…

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

comment:7 Changed 6 years ago by julian.reschke@…

From [2275]:

record change (see #445)

comment:8 Changed 6 years ago by julian.reschke@…

From [2311]:

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

comment:9 Changed 6 years ago by mnot@…

  • Resolution incorporated deleted
  • Status changed from closed to reopened

comment:10 Changed 6 years ago by mnot@…

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.