Re: Suspected errata on 7540 wrt stream states

On Wed, Dec 27, 2017 at 02:54:46PM +0100, Willy Tarreau wrote:
> Hi Ilari,
> 
> 
> But there are not that many ways to reach the closed state :
>   - END_STREAM in both directions
>   - RST_STREAM in any direction
> 
> Also by definition, a closed stream is ... closed. So when you receive a
> frame for such a stream most of the time you don't remember what condition
> caused it to be closed.

The spec requires distinguishing:

1) Stream was "recently" fully closed by RST_STREAM you sent.
2) Stream was "recently" fully closed by END_STREAM you sent (impiles
   that the other side has sent END_STREAM before).
3) Any other case (not "recently" closed, or remote side fully closed
   it via RST_STREAM or END_STREAM).

There is no upper bound what "recently" means. I would expect at least
tens of seconds if not minutes.

In case 1)

- PUSH_PROMISE is processed normally.
- PRIORITY is processed normally.
- DATA updates connection window, but is otherwise ignored.
- All other frames are ignored.

In case 2)

- PRIORITY is processed normally.
- WINDOW_UPDATE is ignored.
- RST_STREAM is ignored.
- All other frames trigger connection error.

In case 3)

- PRIORITY is processed normally.
- All other frames trigger connection error.

> > So if RST_STREAM is not involved, it depends on if you have sent
> > END_STREAM.
> > 
> > 1) If no, it is stream error.
> > 2) If yes, it is connection error.
> 
> But if you haven't sent END_STREAM (case 1), the only way it may end
> up in closed state is by receiving RST_STREAM, which contradicts the
> condition :-)

Case 1 is half-closed case. Case 2 is full close.

> > (Not that this makes very much sense, but at least the spec does not
> > seem to conflict with itself).
> > 
> > 
> > Then there is more whacky case if RST_STREAM is involved:
> > 
> > If you have sent RST_STREAM and then receive END_STREAM and then DATA
> > (all in "short" succession), that is no error.
> 
> Well, I'm starting to think that I will fall back all these situations to
> connection error, given that a stream error may always be elevated to a
> connection error. It will cover all these cases at once.

Just beware that you don't send connection errors on any possibly racy
case. Because such implementation is buggy and such spec is errorneous.


-Ilari

Received on Wednesday, 27 December 2017 14:56:21 UTC