Re: Issue with the H2 state machine

On Fri, Jul 21, 2017 at 11:57:20AM +0300, Ilari Liusvaara wrote:
> 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.

But if a DATA frame follows, the END_STREAM is on the DATA frame, not the
headers frame. There's even exactly this example in 8.1.3 page 59. That's
indeed a bit confusing :-/

Willy

Received on Friday, 21 July 2017 09:03:39 UTC