Re: Working Group Last Call: Bootstrapping WebSockets with HTTP/2

On April 4, 2018 2:10:05 AM GMT+08:00, Alessandro Ghedini <alessandro@ghedini.me> wrote:
>On Thu, Mar 29, 2018 at 11:38:35AM -0400, Bence Béky wrote:
>> Hi,
>> 
>> I would like to propose to add some language to the specification
>about
>> END_STREAM flag on DATA frames.  The example in Section 5.1
>>
><https://tools.ietf.org/id/draft-ietf-httpbis-h2-websockets-01.html#rfc.section.5.1>
>> indicates END_STREAM on the last DATA frames, but these is no other
>mention
>> of this flag.  Chromium's implementation currently does not set the
>> END_STREAM flag on any DATA frames sent, but instead resets the
>stream when
>> it's destructed, which I do not believe is the most elegant approach.
>> 
>> Something along the lines of "Peers MUST set the END_STREAM flag
>(defined
>> in RFC7540 Section 6.1) on any DATA frame sent that contains the
>entirety
>> of or the last fragment of a WebSocket Close frame (defined in
>RFC6455
>> Section 5.5.1).", appended to the end of Section 5, just above 5.1.
>
>As worded, in the aforementioned HTTP/2<->HTTP/1.1 transparent proxy
>case, this
>would require the proxy to inspect and parse the WS frames to detect
>when the
>HTTP/1.1 origin (or client) sends a Close frame, instead of just
>blindly
>proxying data as is currently the case for HTTP/1.1<->HTTP/1.1. So I'd
>relax
>the MUST to a SHOULD, or explicitly exclude proxies from the
>requirement.

Ws close frames are entirely optional, closing the h1 connection to logically end the ws link is also prone to happening at any time.  So I agree no point with the MUST, RST_STREAM will also have to be an equally legit option since it may be no CLOSE will come.  Then the intermediary can just have the simple policy of RST_STREAM when the h1 link goes away.

-Andy

>Otherwise looks good to me.
>
>Cheers