Re: Alt-Svc with UPGRADE

I've reread the httpbis-p1-messaging spec and noticed that I was totally
wrong.
A client can request multiple protocols, so the correct way in this case is
requesting the resource with "Upgrade: WebSocket, h2ws".

This is a little more complicated for thewebsocketprotocol, because
> there is an intrinsic state that is bound to a connection; the
> original connection has something of a state commitment.  This is
> different to HTTP/2, where there is basically no application-layer
> commitment to the connection.

Yes, we should replay the opening handshake if h2ws is selected by the
server.
It is inefficient, but it's not a problem because this rarely happens I
think.

Thanks for the clarification and sorry for bothering you.


On Wed, Apr 2, 2014 at 2:13 AM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 1 April 2014 01:24, Yutaka Hirano <yhirano@google.com> wrote:
> > It would be great if the Alt-Svc response header is applied to the
> upgraded
> > service (in this example, WebSocket, not HTTP).
> > I think UPGRADE users not only WebSocket will be happy with that rule.
>
> I'm not sure that the distinction is necessary.  This is a signal that
> the resource identified in the request can (probably) be found by
> using the identified alternative.  It shouldn't matter if an upgrade
> occurs during the request.
>
> Practically speaking, a client should complete the request, including
> the upgrade.  Then they can make an assessment about whether to a) act
> on the alt-svc suggestion, and then - if the alt-svc works - b) switch
> over to using it.
>
> This is a little more complicated for thewebsocketprotocol, because
> there is an intrinsic state that is bound to a connection; the
> original connection has something of a state commitment.  This is
> different to HTTP/2, where there is basically no application-layer
> commitment to the connection.
>
> --Martin
>