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.

> 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

Received on Monday, 29 September 2014 19:36:50 UTC