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

I don't think we need to add new normative language here - just some
explanatory text that would be helpful.

The model is that the h2 stream is treated like the h1 connection. RST and
END_STREAM have direct h1 connection correlaries (i.e. TCP RST and TCP FIN)
and the handling should be the same (modulo scope of stream vs connection).
I can add an explainer sentence without adding requirements or restating
(perhaps incorrectly?) what 6455 has to say.

On Tue, Apr 3, 2018 at 2:40 PM, Andy Green <andy@warmcat.com> wrote:

>
>
> 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
>
>