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

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

That's an important semantic difference, thanks for highlighting it. If
that's the case, then returning a token like 443:tls-alpn-http/2 makes no
sense, since that would be on a separate connection, right? I think if
we're solely speaking about this connection, then a naked HTTP/2 string is
sufficient (and if you wanted to do StartTLS, you could use a different
string).


On Tue, Apr 23, 2013 at 3:15 PM, Mark Nottingham <[e-mail]> wrote:

> Keep in mind that Upgrade on a non-101 response is about advertising the
> possibility to upgrade *this* connection, whereas Alternate-Protocol is
> about advertising the potential to upgrade by switching connections.
>
>
> On 24/04/2013, at 3:16 AM, William Chan (陈智昌) <[e-mail]>
> wrote:
>
> > 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/
> >
> >
> >
> >
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>