Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

[Andy Green <[e-mail]>]

On 10/27/2017 05:47 AM, John Fallows wrote:

> The current proposal for WebSocket over HTTP/2 seems to be following a 
> similar approach to that described above at the moment, with the HEADERS 
> frame (requiring special-case processing of CONNECT) and first DATA 
> frame both needed to process the server-side WebSocket handshake over 
> HTTP/2.
> 
> Suggest we instead fold the origin and relevant RFC-6455 defined HTTP 
> headers into the HEADERS frame for simplicity, recognizing as Mark noted 

While I think the first draft, second draft or this suggestion are 
already good enough and get the result of eliminating the tcp + tls 
setup for ws needed today, I also thought that was what was going to 
happen in the second draft.

> that CONNECT is not really intended for use directly at the origin 
> server, and instead use a TUNNEL method with corresponding :protocol 
> pseudo-header, where the value of the TUNNEL :protocol pseudo-header 
> drives the expectation of additional HTTP/2 headers that should be present.
> 
> [[ From Client ]]                        [[ From Server ]]
> 
>                                              SETTINGS
>                                              ENABLE_TUNNEL_PROTOCOL = 1
> 
> HEADERS + END_HEADERS
>     :method = TUNNEL
>     :protocol = websocket
>     :scheme = https
>     :path = /chat
>     :authority = server.example.com:443 <http://server.example.com:443>
>     origin = http://www.example.com
> sec-websocket-protocol = chat, superchat
> sec-websocket-version = 13
> 
>                                              HEADERS + END_HEADERS
>                                              :status = 200
> sec-websocket-protocol = chat
> 
>     DATA
>     WebSocket Frames
> 
>                                              DATA + END_STREAM
>                                              WebSocket Frames
> 
>     DATA + END_STREAM
>     WebSocket Frames
> 
> Note also that the scheme is "https" rather than "wss" because the HTTP 
> request is still "https" until *after* the TUNNEL has been established, 
> and the TUNNEL protocol being selected is based on :protocolheader 
> rather than the :schemeheader.
> 
> Hope this is helpful and interested to hear your thoughts and feedback.

This is also simpler for me in two ways, a) headers remain headers and 
b) we don't need a new state machine to parse the DATA before it becomes 
ws traffic... DATA is only used to carry the tunnelled traffic which is 
better.  If you use a funky :method + :protocol or similar if a new 
pseudoheader makes trouble, no need for a DATA probe to upset things 
that don't understand.  Things that didn't understand and think they are 
getting a normal h2 stream will either kill the stream on the, to them, 
illegal method, or if not will kill the stream on the first DATA anyway 
because -->

The spec still needs to touch on the changes it is making to h2 DATA 
frames, it assumes it is inheriting generic bidirectional transport from 
h2, but it isn't.  H2 DATA kills the stream if it comes outside of 
whatever was told for content-length: on both sides, and eg h2spec 
requires you to enforce that.  So the spec requires changes in DATA 
handling implementation for upgraded streams and should note it.

It should probably note there is no relationship between H2 DATA frames 
and the tunneled content, and that the DATA frames may be refragmented. 
It wouldn't hurt to notice that WINDOW_UPDATE is still required / applies.

-Andy