Subject: [hybi] WebSocket over HTTP/2.0 protocol negotiation

From: Yutaka Hirano <[email-masked]>
Date: Thu, 30 Jan 2014 15:45:21 +0900

Hi,

As I announced, I've updated the draft and requested for comments.
Tobias gave a comment on protocol negotiation (thanks!) and I think it is
good to discuss here, not at the draft comment fields.

The draft says:

   1. If the client has a HTTP/2.0 session established by previous requests
   and it doesn’t know that the session does NOT support WebSocket layering
   over HTTP/2.0, create a WebSocket stream on the session. Both of WebSocket
   (ws) and secure WebSocket (wss) could share the same HTTP/2.0 session.
   2. If the client is going to establish a secure WebSocket connection,
   create a WebSocket connection over TLS.
   3. If the client is going to establish a non-secure WebSocket
   connection, try the WebSocket protocol negotiation.

Tobias doesn't like the first step. He says:
>
> I think native WS should be tried first. Native WS has less overhead than
> any WS-over-SPDY layering, and hence should be preferred.

I have some comments about it.
 - WebSocket over HTTP/2.0 is multiplexed, so it is not so obvious which is
preferable. I think it depends on the popularity of the services:
   - WebSocket over HTTP/2.0
   - Native WebSocket and HTTP/2.0
   - Native WebSocket and WebSocket over HTTP/2.0
   Note that servers which doesn't support HTTP/2.0 don't matter, because
they don't meet the precondition of the first step.
 -  There are two scheme negotiation hints described below.
    If we choose Hint X, before receiving a SETTINGS frame from the server,
the client doesn't know which service is preferable. It is rare, but trying
connecting to the wrong service can occur.
    If we choose Hint Y, whether the server supports WebSocket over
HTTP/2.0 or not is detected by the client prior to HTTP/2.0 session
establishment and hence the client always understands the server's
preference.
    So, the actual negotiation decision process depends on the hint we
choose.

I'm sorry that the draft is not clear at this point, but it will be when
the hint is chosen.

Thanks,

---

From: Tobias Oberstein <[email-masked]>
Date: Thu, 30 Jan 2014 04:24:43 -0800

Hi Yutaka,

the point I was trying to raise is this:

For a JavaScript in a browser that opens a "ws://…" connection, there should never be an additional roundtrip
incurred by first probing for any SPDY/WS and then falling back to native WS, but the native WS should be
tried first.

In other words: the current, immediate connection establishment for native WS should not be put
at an disadvantage just because of introducing any SPDY/WS.

A server should be able to provide both SPDY and native WebSocket on the _same_ origin without
being required to implement SPDY/WS also, and without incurring an additional roundtrip for
probing SPDY/WS while establishing a WS connection.

In other words: I think a server should actively announce support for any SPDY/WS, and only then
should SPDY/WS be tried first when a JS opens a WebSocket connection to an origin that has an
existing SPDY connection and which already announced it's support and willingness to speak
any SPDY/WS.

Probably I misunderstood the draft.

Are browsers supposed to work like above when they implement any SPDY/WS?

/Tobias

Von: hybi [mailto:[email-masked]] Im Auftrag von Yutaka Hirano
Gesendet: Donnerstag, 30. Januar 2014 07:45
An: [email-masked]
Betreff: [hybi] WebSocket over HTTP/2.0 protocol negotiation

Hi,

As I announced, I've updated the draft and requested for comments.
Tobias gave a comment on protocol negotiation (thanks!) and I think it is good to discuss here, not at the draft comment fields.

The draft says:

 1.  If the client has a HTTP/2.0 session established by previous requests and it doesn’t know that the session does NOT support WebSocket layering over HTTP/2.0, create a WebSocket stream on the session. Both of WebSocket (ws) and secure WebSocket (wss) could share the same HTTP/2.0 session.
 2.  If the client is going to establish a secure WebSocket connection, create a WebSocket connection over TLS.
 3.  If the client is going to establish a non-secure WebSocket connection, try the WebSocket protocol negotiation.
Tobias doesn't like the first step. He says:
I think native WS should be tried first. Native WS has less overhead than any WS-over-SPDY layering, and hence should be preferred.

I have some comments about it.
 - WebSocket over HTTP/2.0 is multiplexed, so it is not so obvious which is preferable. I think it depends on the popularity of the services:
   - WebSocket over HTTP/2.0
   - Native WebSocket and HTTP/2.0
   - Native WebSocket and WebSocket over HTTP/2.0
   Note that servers which doesn't support HTTP/2.0 don't matter, because they don't meet the precondition of the first step.
 -  There are two scheme negotiation hints described below.
    If we choose Hint X, before receiving a SETTINGS frame from the server, the client doesn't know which service is preferable. It is rare, but trying connecting to the wrong service can occur.
    If we choose Hint Y, whether the server supports WebSocket over HTTP/2.0 or not is detected by the client prior to HTTP/2.0 session establishment and hence the client always understands the server's preference.
    So, the actual negotiation decision process depends on the hint we choose.

I'm sorry that the draft is not clear at this point, but it will be when the hint is chosen.

Thanks,