Re: HTTP/2 and Websockets

>
> On Mon, Sep 29, 2014 at 08:36:51PM +0900, Yutaka Hirano wrote:
> > Thank you for the comments!
> >
> > We have been not working actively for months because of two reasons:
> > 1) The http/2 spec was changing rapidly and we couldn't write a spec on
> top
> > of it.
> > 2) We weren't confident if wide range of people were interested in this
> > protocol.
> >
> > 1) will be resolved soon, I hope. For 2), If you are interested in
> > WebSocket over HTTP/2, it is very helpful to express it!
> > About one year ago, we were talking if we wanted perfect RFC6455
> compatible
> > WebSocket or not (i.e. full-extension support). IIRC most of us didn't
> want
> > the full RFC6455 compatibility, but if you have any opinion, it is
> welcome.
> > In short, we would like to hear your voice.
> Couple points:
> - It was just quick sketch using the standard "first idea that isn't known
>   broken" way of problem solving.
> - That sketch does not have full RFC6455 compability. Some kinds of
> extensions
>   don't work (PMCE just happens to work).
> - Some obvious-looking mappings don't work. E.g. one can't map Websockets
>   PING to HTTP/2 PING (different scope).
> - There should not be lots of HTTP2 header frames. Those are rather heavy,
>   and thus increase resource usage. Control frames could be a possiblity,
>   but I'd rather not have data frames use those (which would exclude using
>   headers for delimiting frames).
> - Mapping control frames to headers would be a possiblity. But even so, the
>   semantics would likely be close enough for automatic translation at proxy
>   to be possible.
> - Automatic translation between WS1 and WS2 could be useful together with
>   proxies capable of HTTP1<->HTTP2 translation.

"Full RFC6455 compatibility" means that the WebSocket over HTTP/2 can
express any data represented by the native WebSocket. For example, we can't
modify any WebSocket frame boundary if we decide to respect RFC6455. Please
see the long discussion starting from:
http://www.ietf.org/mail-archive/web/hybi/current/msg10266.html .
My opinion is we don't have to keep the full RFC6455 compatibility and
hence we can't have a general translation.


>
> > I would just signal SETTINGS_WEBSOCKET_CAPABLE with 0x1-bit set to 1 (and
> > > the rest reserved for extension) from server (or from proxy towards
> > > client).
> > > After receiving SETTINGS_WEBSOCKET_CAPABLE with 0x1 flag, the client/
> > > proxy knows the proxy/server can handle websockets (and is used via
> > > :scheme 'ws'/'wss'). No need to ACK anything.
> >
> > My proposal doesn't need ACK.
> > The client sends a SETTINGS frame before sending the first handshake in
> the
> > stream. After that, the client starts the usual WebSocket opening
> handshake.
> The client needs to know if server supports WS2. Otherwise, the client
> could
> send ws:// or wss:// URL to server that does not support WS2, and that is
> "undefined behaviour" (HTTP 4xx/5xx, stream error, connection error(!) or
> the worst of all, HTTP 200(!!!)).
> I don't see any point in changing server behaviour based on
> SETTINGS_WEBSOCKET_CAPABLE. Clients without WS2 support won't send WS2
> handshakes. WS2-supporting clients may send those, to servers known to
> support WS2.
> Similar considerations apply for intermediaries.

Yeah, In my proposal, the client knows the server's preference via ALPN (or
ALT-SVC). That way, we can create a WebSocket connection without
introducing an additional RTT in typical cases.
The design principal there is
 - We don't want to introduce an additional RTT if the server doesn't
implement WebSocket over HTTP/2.
 - We don't want to introduce an additional RTT in typical cases if the
server implement WebSocket over HTTP/2.
SETTINGS_WEBSOCKET_CAPABLE is needed for the complete communication path
including intermediaries (and for introducing new frame types).


>
> > One way would be to take the base Websockets spec for data communications
> > > and rip out everything unneeded and adapt some things:
> >
> > Given that we have SETTINGS_WEBSOCKET_CAPABLE, I would use a new frame
> type
> > not to confuse intermediaries / endpoints. The actual data format will be
> > discussed, but IMHO it is less important and can be discussed later.
> I can't see how such confusion could happen. Intermediary/endpoint is
> known WS2-capable and the stream is designated as WS2 in the opening
> handshake.
> Or is this about dealing with really buggy intermediaries/endpoints?

One of lessons learned from the existing WebSocket is that many
intermediaries interpret what they should not interpret. See
http://w2spconf.com/2011/papers/websocket.pdf for example.
As the HTTP/2 spec allows us to create new frame types, doing so looks
safer.



On Tue, Sep 30, 2014 at 4:36 AM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> On Mon, Sep 29, 2014 at 08:36:51PM +0900, Yutaka Hirano wrote:
> > Thank you for the comments!
> >
> > We have been not working actively for months because of two reasons:
> > 1) The http/2 spec was changing rapidly and we couldn't write a spec on
> top
> > of it.
> > 2) We weren't confident if wide range of people were interested in this
> > protocol.
> >
> > 1) will be resolved soon, I hope. For 2), If you are interested in
> > WebSocket over HTTP/2, it is very helpful to express it!
> > About one year ago, we were talking if we wanted perfect RFC6455
> compatible
> > WebSocket or not (i.e. full-extension support). IIRC most of us didn't
> want
> > the full RFC6455 compatibility, but if you have any opinion, it is
> welcome.
> > In short, we would like to hear your voice.
>
> Couple points:
> - It was just quick sketch using the standard "first idea that isn't known
>   broken" way of problem solving.
> - That sketch does not have full RFC6455 compability. Some kinds of
> extensions
>   don't work (PMCE just happens to work).
> - Some obvious-looking mappings don't work. E.g. one can't map Websockets
>   PING to HTTP/2 PING (different scope).
> - There should not be lots of HTTP2 header frames. Those are rather heavy,
>   and thus increase resource usage. Control frames could be a possiblity,
>   but I'd rather not have data frames use those (which would exclude using
>   headers for delimiting frames).
> - Mapping control frames to headers would be a possiblity. But even so, the
>   semantics would likely be close enough for automatic translation at proxy
>   to be possible.
> - Automatic translation between WS1 and WS2 could be useful together with
>   proxies capable of HTTP1<->HTTP2 translation.
>
> > I would just signal SETTINGS_WEBSOCKET_CAPABLE with 0x1-bit set to 1 (and
> > > the rest reserved for extension) from server (or from proxy towards
> > > client).
> > > After receiving SETTINGS_WEBSOCKET_CAPABLE with 0x1 flag, the client/
> > > proxy knows the proxy/server can handle websockets (and is used via
> > > :scheme 'ws'/'wss'). No need to ACK anything.
> >
> > My proposal doesn't need ACK.
> > The client sends a SETTINGS frame before sending the first handshake in
> the
> > stream. After that, the client starts the usual WebSocket opening
> handshake.
>
> The client needs to know if server supports WS2. Otherwise, the client
> could
> send ws:// or wss:// URL to server that does not support WS2, and that is
> "undefined behaviour" (HTTP 4xx/5xx, stream error, connection error(!) or
> the worst of all, HTTP 200(!!!)).
>
> I don't see any point in changing server behaviour based on
> SETTINGS_WEBSOCKET_CAPABLE. Clients without WS2 support won't send WS2
> handshakes. WS2-supporting clients may send those, to servers known to
> support WS2.
>
> Similar considerations apply for intermediaries.
>
> > One way would be to take the base Websockets spec for data communications
> > > and rip out everything unneeded and adapt some things:
> >
> > Given that we have SETTINGS_WEBSOCKET_CAPABLE, I would use a new frame
> type
> > not to confuse intermediaries / endpoints. The actual data format will be
> > discussed, but IMHO it is less important and can be discussed later.
>
> I can't see how such confusion could happen. Intermediary/endpoint is
> known WS2-capable and the stream is designated as WS2 in the opening
> handshake.
>
> Or is this about dealing with really buggy intermediaries/endpoints?
>
>
> -Ilari
>