- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 30 Apr 2013 13:20:14 +1000
- To: Willy Tarreau <w@1wt.eu>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
I'm going to mark this resoution for incorporation into -23. On 23/04/2013, at 6:12 PM, Willy Tarreau <w@1wt.eu> wrote: > Hi Mark, > > On Tue, Apr 23, 2013 at 05:38:59PM +1000, Mark Nottingham wrote: >> 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. >> """ > > 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 > > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 30 April 2013 03:20:42 UTC