Re: p1: Upgrade ordering (possible HTTP/2 impact)

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.

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/
>
>
>
>
>