Re: INVALID_STREAM and STREAM_ALREADY_CLOSED

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.

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


On Tue, Mar 26, 2013 at 12:34 PM, Roberto Peon <grmocg@gmail.com> wrote:

> imho: Seems reasonable for now.
> 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.
>
> -=R
>
>
> On Tue, Mar 26, 2013 at 11:23 AM, Martin Thomson <martin.thomson@gmail.com
> > wrote:
>
>> Another error code question.
>>
>> INVALID_STREAM indicates that a frame arrived for an "inactive" stream.
>>
>> STREAM_ALREADY_CLOSED indicates that a frame arrived for a (half-)closed
>> stream.
>>
>> Both are unexpected frames.  My first inclination was to suggest
>> (again) that a single error code was appropriate.
>>
>> However, if I read between the lines, INVALID_STREAM is as a result of
>> getting a frame prior to the first 'official' frame in the stream
>> (i.e., SYN_STREAM).  But the general design doesn't require that a
>> stream starts with any particular frame.
>>
>> So I conclude that it only makes sense to have STREAM_ALREADY_CLOSED.
>>
>>
>