W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Ending streams/connections

From: Greg Wilkins <gregw@intalio.com>
Date: Wed, 3 Sep 2014 22:07:38 +1000
Message-ID: <CAH_y2NEAF=NNSGEsAvNH4dHGCHsKFZ=6XsOsq-0uv4UQVj9xOg@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 3 September 2014 18:07, Cory Benfield <cory@lukasa.co.uk> wrote:

> Not quite. The END_STREAM flag doesn't terminate a stream, it closes
> one end of a stream. This is not what RST_STREAM does: RST_STREAM
> closes *both* ends of the stream. If i receive an END_STREAM flag from
> you that tells me that you can't send me any more non-control frames
> on that stream, but does not prevent me sending you more. RST_STREAM
> does (or at least should).
>

My bad - I forgot that RST is not acknowledged.   I had thought that it was
effectively a half close with the extra condition that when you receive a
RST, you
had to send one immediately, hence forcing the full close (but above the
framing layer).

But I now (belatedly) remember that it is not acknowledged and that

   after sending the RST_STREAM, the sending endpoint
   MUST be prepared to receive and process additional frames sent on the
   stream that might have been sent by the peer prior to the arrival of
   the RST_STREAM.

It's a little bit strange that we insist that settings frames are
acknowledged but
have to have a  'short period' when the stream is quasi closed.

Anyway - ignore me.  I had thought it was a minor tidy up, but does not
work with this complex closed state.

cheers

-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.
Received on Wednesday, 3 September 2014 12:08:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC