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

[William Chan (陈智昌) <[e-mail]>]

I think adding the relative preference semantic is good.

I have to confess I was not aware of using Upgrade as a response header
outside of a 101 or 426 response. This indeed sounds very similar to
Alternate-Protocol. Is anyone actually using this in practice?


On Tue, Apr 23, 2013 at 2:46 AM, Roberto Peon <[e-mail]> wrote:

> Excellent. Almost at the point of not needing alternate-protocol. :)
>
> The last difference here is that alternate-protocol allows the client to
> cache this data, so that it may negotiate the new protocol (on some future
> connection) potentially without being forced to do an upgrade.
>
> Today, this mainly is interesting for resources with an http scheme being
> served over an encrypted channel where the upgrade isn't necessary. With
> the value in the upgrade field cached, the browser can see an http scheme
> for that origin and immediately make an ALPN-negotiated connection
>
> -=R
>
>
> On Tue, Apr 23, 2013 at 2:35 AM, Mark Nottingham <[e-mail]> wrote:
>
>> On 23/04/2013, at 7:24 PM, Roberto Peon <[e-mail]> 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 <[e-mail]> wrote:
>> > WFM
>> >
>> > On 23/04/2013, at 6:12 PM, Willy Tarreau <[e-mail]> 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/
>>
>>
>>
>>
>