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

[Andy Green <[e-mail]>]

On October 15, 2017 11:43:02 PM GMT+08:00, Cory Benfield <[e-mail]> wrote:

Cory, thanks for cc-ing hybi.  I reply with comments about the draft first.

1) it's great that after a few years someone with influence woke up to the fact ws was frozen out of h2 and that, as was publicly foreseen by several people, it would be a PITA to leave it at "let them eat h1".

2) 'From the draft: 'A server offering both HTTP/1.1 and WebSocket services can do so from the same instance and same port although they require separate TCP connections. Moving a server to HTTP/2 and WebSocket services requires a separate port and protocol stack for the sole purpose of bootstrapping WebSockets. This is a significant administrative burden and may not even be possible in the case of large amounts of deployed markup pointing at the old single name and port. ''

This simply isn't true, for example libwebsockets supports h1, h2 and wss all on :443 simultaneously; https://libwebsockets.org itself runs on that today.  Nothing stops it except decisions made by the server authors.  "Some popular implementations are not architechted in a way the same listen port can accept sockets destined for h1, h2, and ws" or similar would be more correct.

3) The general approach in the draft is okay.  It just adds ws to h2 which is what was always needed. The general occurance of DATA in each direction differs from that implied by http h2 usage, it's not a problem but maybe should be noted.

4) The draft should spell out it carries ws payload unchanged in h2 frames.  In particular ws has this xor "masking" stuff that is just not needed for end-end h2 ws connections.  It's a shame this scheme leaves eliminating the bloat on the table but better (bloatwise) plans have gone around in circles for years, this draft marks a browser implementor actually wanting to implement something related to h2 ws for the first time I heard of...

5) Hybi originally did the ws handshake key dance with hashes to ensure there were no inadvertant ws handshakes where one side did not really speak it.  It is not required on h2, since if it has the SETTINGS enabled, it asserts it speaks it, although I get it a client for a stream may not know it went over h2, only know h1 and require the dance.  So the old dance should be optional I think.

6) If you make the ws key dance roundtrip optional, something to keep h1 clients happy who don't know they're on h2, then you can PUSH_PROMISE a ws upgrade on a specific subprotocol unilaterally, eliminating roundtrips.  If you are serving html with a script that wants to make the ws connection back, it's a very good bet the client would take up the PUSH_PROMISE with very nice latency improvement.

>Doesn’t the introduction of a new pseudo-header field violate RFC 7540
>Section 8.1.2.1, which says endpoints MUST NOT generate new
>pseudo-header fields?
>
>Or is the position that that MUST NOT implicitly applies only if there
>are no negotiated extensions in use?

That is a good point... won't a new Sec-whatever do?  Being able to use whatever it is in PUSH_PROMISE to unilaterally offer an unambiguous pre-upgraded ws stream would be very nice.

-Andy

>Cory
>
>> On 15 Oct 2017, at 07:12, Patrick McManus <[e-mail]>
>wrote:
>> 
>> FYI - also see
>https://github.com/mcmanus/draft-h2ws/blob/master/README.md
>> 
>> Comments, expressions of interest, etc are very welcome.
>> 
>> 
>> ---------- Forwarded message ----------
>> From: <[e-mail]>
>> Date: Sun, Oct 15, 2017 at 10:08 AM
>> Subject: New Version Notification for
>draft-mcmanus-httpbis-h2-websockets-00.txt
>> To: Patrick McManus <[e-mail]>
>> 
>> 
>> 
>> A new version of I-D, draft-mcmanus-httpbis-h2-websockets-00.txt
>> has been successfully submitted by Patrick McManus and posted to the
>> IETF repository.
>> 
>> Name:           draft-mcmanus-httpbis-h2-websockets
>> Revision:       00
>> Title:          Bootstrapping WebSockets with HTTP/2
>> Document date:  2017-10-15
>> Group:          Individual Submission
>> Pages:          7
>> URL:           
>https://www.ietf.org/internet-drafts/draft-mcmanus-httpbis-h2-websockets-00.txt
>> Status:        
>https://datatracker.ietf.org/doc/draft-mcmanus-httpbis-h2-websockets/
>> Htmlized:      
>https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-00
>> Htmlized:      
>https://datatracker.ietf.org/doc/html/draft-mcmanus-httpbis-h2-websockets-00
>> 
>> 
>> Abstract:
>>    This document defines a mechanism for running the WebSocket
>Protocol
>>    [RFC6455] over a single stream of an HTTP/2 connection.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of
>submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>>