- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 23 Apr 2013 19:35:21 +1000
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Willy Tarreau <w@1wt.eu>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 23/04/2013, at 7:24 PM, Roberto Peon <grmocg@gmail.com> wrote: > A complication here is that it isn't sufficient to state the protocol as HTTP/2 > As an example assuming we may wish to use the version that negotiates using ALPN over TLS/:443, we'd be unhappy unless we become more specific about what the various version strings for (at least) HTTP/2 will mean in this field. I think that's the plan... > In alternate-protocol, this was dealt with by having different version strings for the possibly different negotiation mechanisms (though nothing but NPN was really used), e.g. > npn-http/2 vs http/2 or, more completely, 443:npn-http/2 or 80:http/2 > > -=R > > > On Tue, Apr 23, 2013 at 1:14 AM, Mark Nottingham <mnot@mnot.net> wrote: > WFM > > 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/ > > > > > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 23 April 2013 09:35:49 UTC