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. > >CheersReceived on Tuesday, 3 April 2018 18:41:53 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC