Subject: Re: [hybi] Revising handshake and AddChannelRequest considering HTTP/2.0

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 2 Aug 2012 02:41:57 +0900

On Tue, Jul 31, 2012 at 3:20 AM, Bruce Atherton <[email-masked]> wrote:

>
> These headers (except for ext-for-logical-ch) are meaningful only when
> performing HTTP Upgrade and establishing physical connection.
>
>
> I agree for most of these, but I am uncertain about the Sec-WebSocket-Key.
> The point of that (and the Sec-WebSocket-Accept) is to guarantee that both
> ends are actually WS endpoints. Are there not usecases where a datacenter
> frontend might split a muxed connection and send the channels to different
> servers? If so, I think we need to validate all the endpoints of channels
> by sending a nonce and receiving the correct hash back.
>

Yes. When un-bundling the muxed connection into WebSocket, the frontend
needs to re-add the header and validate the response. It might be a little
load reduction for such intermediaries if we keep Sec-WebSocket-Key/Accept
generated/validated by endpoints and exchanged over mux. But that's all, I
think.

> (
> It looks like moving these headers to mux's extension parameter make
> sense. But please note that we can't do it because of the requirement
> that WebSocket server w/o mux support should be able to accept the
> connection by just rejecting mux extension. Like this:
>
>    HTTP/1.1 101 Switching Protocols
>   ...
>    Sec-WebSocket-Extensions: ext-for-logical-ch
>   ...
> )
>
>
> Do you mean adding any number of headers as parameters to the mux
> extension declaration in the Sec-Websocket-Extensions header? A list of
> headers inside a single header seems needlessly complicated to me, even
> without the need for a fallback for non-muxing servers.
>

Yes.

>
>
>  Response headers are also broken down into two groups. The following
> headers should be excluded from delta encoding base.
>
>    Upgrade: websocket
>   Connection: Upgrade
>   Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
>
>  (It's off topic but needs discussion whether we should send reply to
> implicitly opened channel by physical channel handshake response or we
> should send a separate AddChannelResponse for that. The latter allows
> opening mux connection even when the request for implicitly opened channel
> is bad e.g. 404)
>
>
> IMHO the 404 should result in the connection being handled the same way it
> would for an HTTP XHR request. Ditto for 300 statuses where the resource
> might have moved to another server that requires a different connection to
> be established.
>
> What if, in a particular session, there was only going to be that one
> channel request that had failed? A useless connection would be hanging
> around for no reason. If there is a second channel request that would be
> successful, then that can be the implicitly opened channel that establishes
> the mux connection.
>

Good point.

> If we think of the framing layer as separate from both Websockets and HTTP
> 2.0, we can look at the headers and consider which they belong to.
>
> I think the Upgrade header belongs to the framing layer. Maybe it should
> be "Upgrade: frames" with another header "Sec-Framing-Protocols: http2,
> websocket" to establish the protocols that should be carried. Who knows,
> perhaps eventually there will be others such as a peer-to-peer protocol
> between browsers.
>
>
Yes. We can reuse WebSocket headers but we don't have to. The headers you
suggested may reflect the concept more clearly.

>  A server response could indicate which protocols it actually supported.
> This would not be backward compatible with the WS 1.0 handshake, but
> servers could support both methods fairly easily.
>

Yes.