Re: Issue with the H2 state machine

On Fri, Jul 21, 2017 at 10:39:41AM +0200, Willy Tarreau wrote:
> On Fri, Jul 21, 2017 at 10:17:44AM +0200, Willy Tarreau wrote:
> (...)
> > 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.
> 
> Finally I found that "8.1 HTTP Req/Resp Exchange" more or less addresses
> it by remining a normal sequence though without being very strict on what
> to do when it doesn't match (lack of HEADERS frame not mentionned for
> example). I don't have much better to propose for now however.
> 
> Also I think I found a typo here in 8.1 :
> 
>    An endpoint that receives a HEADERS
>    frame without the END_STREAM flag set after receiving a final (non-
>    informational) status code MUST treat the corresponding request or
>    response as malformed (Section 8.1.2.6).
> 
> I think it should use s/END_STREAM/END_HEADERS/ given that DATA frames
> are still allowed here. I can file an errata if confirmed.

I think it is correct, just somewhat confusing. This seem to be
requirement that there can be at most one header block at the very end
after headers that sends the final status code.

And yes, section 8.1 is pretty clear that the structure of response
stream is.


-Ilari

Received on Friday, 21 July 2017 08:57:46 UTC