Subject: Ending streams/connections

From: Greg Wilkins <[email-masked]>
Date: Wed, 3 Sep 2014 12:11:59 +1000

Currently a stream can end either with a RST_STREAM or with a frame
carrying the  END_STREAM flag.

I propose that RST_STREAM should also indicate end of stream by defining
the END_STREAM(0x1) flag and it MUST be set.

The reason for this proposal is so that code can be written to track the
status of stream without needing to care about the exact semantics of
resetting a stream.

If END_STREAM is moved to the reserved bit, then all we need to is say that
RST_STREAM MUST set the END_STREAM bit in the header.

Similarly, I think that GO_AWAY should also indicate END_STREAM on stream
ID=0

cheers

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Cory Benfield <[email-masked]>
Date: Wed, 3 Sep 2014 09:07:52 +0100

Greg,

On 3 September 2014 03:11, Greg Wilkins <[email-masked]> wrote:
>
> Currently a stream can end either with a RST_STREAM or with a frame carrying
> the  END_STREAM flag.

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

(NB: It's actually suddenly not clear to me what frames END_STREAM
prevents. It definitely prevents more DATA frames, but does it also
prevent further HEADERS frames? If I'm sending trailers, does the last
DATA frame carry END_STREAM and is then followed by HEADERS, or does
the last HEADERS carry END_STREAM?)

> I propose that RST_STREAM should also indicate end of stream by defining the
> END_STREAM(0x1) flag and it MUST be set.

This is harmless: the END_STREAM flag informs the remote party that
you're closing your send portion of the stream, which is already
implied by the fact that RST_STREAM includes that meaning. However,
it's also redundant. Redundancy tends to be bad.

> status of stream without needing to care about the exact semantics of

As I point out above, that's not true. You'll still need to
special-case the RST_STREAM frame's effect on closing your send
channel.

> Similarly, I think that GO_AWAY should also indicate END_STREAM on stream

This is a weird idea, but that might be because of my implementation.
I don't consider stream 0 to be a 'real' stream, I consider it to map
1:1 to the connection. Its state maps directly onto the state of the
connection: stream 0 is open for as long as the connection is.

Additionally, given what I said above about END_STREAM being about
sending non-control frames, END_STREAM has no effect on the state of
stream 0 because you already can't send non-control frames on it.
HEADERS and DATA must be sent on stream != 0, so if you send me
END_STREAM it doesn't change my behaviour at all.

Cory

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 3 Sep 2014 22:07:38 +1000

> 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