Opened 10 years ago
Closed 9 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 10 years ago by mnot@…
- Milestone changed from unassigned to 23
comment:2 Changed 10 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 10 years ago by mnot@…
Also, make "descending" explicit
comment:4 Changed 10 years ago by fielding@…
comment:5 Changed 10 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 10 years ago by julian.reschke@…
Do we need to record this in the changes-from-rfc2616 section?
comment:7 Changed 10 years ago by julian.reschke@…
comment:8 Changed 10 years ago by julian.reschke@…
comment:9 Changed 9 years ago by mnot@…
- Resolution incorporated deleted
- Status changed from closed to reopened
comment:10 Changed 9 years ago by mnot@…
- Resolution set to fixed
- Status changed from reopened to closed
Proposal from list: