Subject: Alt-Svc with UPGRADE

From: Yutaka Hirano <[email-masked]>
Date: Tue, 1 Apr 2014 17:24:28 +0900

Hi,

The Alt-Svc response header can appear in the response of an UPGRADE
request.
I am wondering whether the alt-svc suggestion will be applied to the
original service or to the upgraded service.
What is in my mind is suggesting the WebSocket over HTTP/2 to a native
WebSocket UPGRADE request. When the server supports the WebSocket over
HTTP/2 and the client requests a native WebSocket connection with an
UPGRADE on HTTP/1.1, the server might want to suggest the WebSocket over
HTTP/2 with the Alt-Svc response header.

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.

Thanks,

---

From: Martin Thomson <[email-masked]>
Date: Tue, 1 Apr 2014 10:13:59 -0700

> 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

---

From: Yutaka Hirano <[email-masked]>
Date: Fri, 4 Apr 2014 12:55:28 +0900

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".

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