Re: INVALID_STREAM and STREAM_ALREADY_CLOSED

On 26 March 2013 12:58, William Chan (陈智昌) <willchan@chromium.org> wrote:
> We used INVALID_STREAM to indicate the client received a SYN_STREAM with an
> associated stream id that does not exist. Maybe we should just terminate the
> session.

There are five potential scenarios, all based on the highest stream
identifier already seen:

1. Message with a stream ID that is higher than the last stream
identifier by more than 2.
Conclusion: No real problem here, just a few gaps in the chain that
mean less efficient use fo .

2. Message with a stream ID that is lower (or equal to) the highest
stream identifier.  That stream is still open.
Conclusion: No problem, that's normal operation.

3. Message with a stream ID that is lower (or equal to) the highest
stream identifier.  That stream is (half-)closed.
Conclusion: STREAM_ALREADY_CLOSED.

4. Client generates a frame with an even numbered stream ID/server
uses an odd stream ID. That stream hasn't been used by the peer yet.
Conclusion: The sender of this frame is supposed to wait for its peer
to send before using those streams.  This might warrant a separate
error code.  Is this what INVALID_STREAM is intended to cover?
Exception: RST_STREAM needs to be valid here to allow PUSH_PROMISE to
work properly.

5. Client generates a frame with an even numbered stream ID/server
uses an odd stream ID. That stream ID has already been used.
Conclusion: No problem, that's called a reply - normal operation.

> STREAM_ALREADY_CLOSED can be confusing since peers don't necessarily know
> that it's already closed unless we maintain the set of old closed stream
> ids.

I never imagined that this would be the case:  If you track open
streams, as you must, all streams that you aren't tracking are closed
if they have an ID lower than the highest tracked stream ID.

> And what if we receive DATA frames for non-existent streams? I guess we
> shouldn't RST_STREAM a non-existent stream, since the stream id is invalid.

Be very clear here.  I like to think of streams as having three
states: unused, active, and closed.  (Note that you might consider
these states to apply separately in both directions.)  What states
correspond to 'non-existent'?  How does one convey an invalid stream
ID?

On Tue, Mar 26, 2013 at 12:34 PM, Roberto Peon <grmocg@gmail.com> wrote:
> I expect that we'll expand the error codes as more implementors find error
> conditions that they want to be able to debug from a client debug
> information, at which point we can re-add any of this.

That is very much true..

Received on Tuesday, 26 March 2013 20:34:27 UTC