Re: Questions about stream state transitions

[Martin Thomson <[e-mail]>]

This is really valuable work.

I'm going to create a ticket to cover addressing these points:
https://github.com/http2/http2-spec/issues/175

That one, I'll mark as editorial, but I'll also create a couple of
extra issues (below).

On 17 July 2013 05:39, Shigeki Ohtsu <[e-mail]> wrote:
> Hi,
>
> The stream state is newly introduced in the draft-04. For my understandings,
> I've just wrote a table diagram for the stream states transition to cover
>  all scenarios in the case of sending and receiving frames.
>
> The table is listed in
>
> http://html5.ohtsu.org/HTTP2_Stream_State.pdf

Note that, in general, you will see a great deal of symmetry between
the two tables.  If it is a PROTOCOL_ERROR to receive, then it will be
a MUST NOT for send, aside from the boundary cases where races can
occur.

> In writing this, I have the folowing five questions which are painted gray in
> the table field.
>
> (1) Receiving RST_STREAM in "idle"
> Is it a stream error with PROTOCOL_ERROR or falled into "closed" state?

I believe that the right approach is to treat this as a *connection*
error of type PROTOCOL_ERROR.  Otherwise, an endpoint can be required
to maintain too much extra state.
-> https://github.com/http2/http2-spec/issues/176

> (2) Receivng PRIRORITY and WINDOW_UPDATE in "half closed(local)"
> They are not necessary. So is it to be an error or ignored?

Both can be received in this state.  If you just sent END_STREAM, then
it would not be unexpected to receive either frame shortly thereafter.
 Ignoring them seems safe (providing that you apply the usual DoS
heuristics).

> (3) Sending PRIORITY in "half closed(remote)"
> No description about this case is in the draft. Is it prohibited?

No need to send it, but it's impossible to force compliance (see above answer).

> (4) Receiving RST_STREAM in "closed"
> The draft says that " An endpoint that sends a RST_STREAM frame MUST ignore
> frames that it receives on closed streams after it has sent a RST_STREAM frame."
>
> Is this ignored always in the closed state or only in the case
> after RST_STREAM sent?

If you send RST_STREAM, then receiving RST_STREAM should be OK.  In my
opinion, an implementation could choose to use RST_STREAM as a signal
that they can stop ignoring frames on that streams (and transition to
a  hard connection-level PROTOCOL_ERROR for any other frames that
appear).

If a stream is closed, either because both peers sent END_STREAM, or
you *received* RST_STREAM, receiving RST_STREAM is a PROTOCOL_ERROR.
That, we should clarify.

> (5) Receiving PUSH_PROMISE in "closed"
> The draft says that 'An endpoint might receive a PUSH_PROMISE frame after
> it sends RST_STREAM. PUSH_PROMISE causes a stream to become "reserved".'
>
> The same question above.
> Is PUSH_PROMISE always leads the associted stream to be reserved(remote)
> in the closed state? Or is it limited in the case after RST_STREAM was sent?

This is only valid if you send RST_STREAM.  If you reach "closed" in
any other way, the remote peer is aware of the close and should not be
sending junk.  In this case, perhaps we need to escalate the error to
a connection one, so that we can avoid the need to worry about the
promised stream.

That might be a general principle that can be applied to invalid
PUSH_PROMISE frames, lest we end up with streams that are sort-of
promised, but not promised in any valid way.
-> https://github.com/http2/http2-spec/issues/177

> If any missings or mistakes are found in the table, I'm very glad to have feedbacks.

I think that you have the PUSH_PROMISE a little wrong, depending on
which stream that you are talking about.

The stream that you are using here is the *promised* stream.  But the
frame header for PUSH_PROMISE includes the *associated* stream.
Perhaps you need to add another column for the effect that
PUSH_PROMISE has on the associated stream.