W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Alt-Svc with UPGRADE

From: Yutaka Hirano <yhirano@google.com>
Date: Fri, 4 Apr 2014 12:55:28 +0900
Message-ID: <CABihn6EoAHVHd1KuUsUBXnGfz_dnU-CYr4pqaHNDNVpZ2B9nEg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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
>
Received on Friday, 4 April 2014 03:55:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC