Issue with the H2 state machine

Hi,

I'm having issues with the H2 state machine, it doesn't differenciate the
direction enough, explicitly allowing some incorrect transitions that
caused me some long head-scratching sessions. One of them is the following :

    IDLE
      |
      | recv HEADERS
      V
    OPEN
      |
      | recv ES
      V
    HALF
   CLOSED
   REMOTE
      |
      :

Here the spec explicitly says regarding DATA frames in 6.1 :

  DATA frames are subject to flow control and can only be sent when a
  stream is in the "open" or "half-closed (remote)" state.
      
Then 6.2 for the HEADERS frame :

   HEADERS frames can be sent on a stream in the "idle", "reserved (local)",
   "open", or "half-closed (remote)" state.

This causes the fact that if we stick to the text, it's perfectly valid
to receive a request, stay in OPEN or go to the HALF-CLOSED(REMOTE) states
depending on the presence of ES on the received HEADERS frame, then decide
to send DATA frames without a prior HEADERS frame, and even to send a
HEADERS frame after the DATA frames if desired. And I didn't find anything
in the text allow the client to reject such a malformed response.

I'm not seeing anything explicitly forbidding to send this sequence. I'm
obviously not interested in doing it, but I found it while trying to use
the stream state to know what I have to do when getting back to processing
a stream, and found that each time I adapted my model differently, I broke
it another way. I'm thinking about adding sub-states to deal with this here,
but I wanted to check if 1) I'm overlooking something (or am completely
stupid) and 2) if some implementations sticking strictly to the specified
state machine could possibly face issues when dealing with such sequences.

Cheers,
Willy

Received on Friday, 21 July 2017 08:18:07 UTC