W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

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

From: Andy Green <andy@warmcat.com>
Date: Wed, 04 Apr 2018 02:40:52 +0800
To: ietf-http-wg@w3.org,Alessandro Ghedini <alessandro@ghedini.me>,Bence Béky <bnc@chromium.org>
CC: Mark Nottingham <mnot@mnot.net>,HTTP Working Group <ietf-http-wg@w3.org>,Patrick McManus <mcmanus@ducksong.com>
Message-ID: <44B826DA-859C-4D69-8E8D-4FB488B16B91@warmcat.com>


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
Received on Tuesday, 3 April 2018 18:41:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:20 UTC