RE: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME

[Mike Bishop <[e-mail]>]

As Lucas said, if you have a separate parser by stream type and the frames defined for other streams simply aren't handled, that would violate the MUST-error requirements we currently have.  You would fail a compliance test.



I see a couple separable questions that we need to answer to move forward here:

  *   Should this even be possible?  QUIC has established a pattern of making it impossible to send invalid values.  An H3 incarnation of that pattern would be to split the frame type spaces so there's no such thing as WRONG_STREAM, just unknown frame types.  Should WRONG_STREAM be possible to express?
  *   If so, is this error easily detectable?  We've established a principle that easily detected protocol violations will be required to generate an error.  The current text reflects this principle, since known frame types and their valid streams are easily detectable.
     *   If the pattern Martin suggests might be common, and therefore this error isn't "easily detected," these would become SHOULD-error instead.
  *   Only then, the original question, is there value in having separate error codes?



I find the separate frame type registries slightly attractive, but unless we cross-reserve values (which defeats the point), we'd be breaking the last vestiges of HTTP/2 resemblance.  It's also a pretty fundamental change for a protocol on the edge of late-stage process.  I don't think I'd want to bite that off unless the working group as a whole feels strongly that it's an improvement, and I'm not seeing that so far.



I tend to think that misuse of known frame types is easily detectable and therefore Martin's hypothetical implementation is simply wrong.  However, the value in the distinction between the two seems minimal.  I'd vote for merging.



-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Martin Thomson
Sent: Tuesday, August 6, 2019 8:29 PM
To: [e-mail]
Subject: Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME



On Wed, Aug 7, 2019, at 10:03, Lucas Pardue wrote:

> As part of the HTTP error analysis and feedback, in June I created

> issue #2809 "Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME"

> [1].



The notion of a signal for "I got a frame that I understood, but it was in the wrong place" is fine.  Good even.  But I don't see a need to have two such signals.  So I'm in favour of collapsing the two.  I don't understand the distinction between these signals as it stands anyway.



However, I'm also concerned that this is going to get wrapped up in the usual compliance test mess.  If I hook up different parsers on different streams and my request stream parser doesn't know about SETTINGS at all, so ignores it when it suddenly appears on a request stream, is the test case going to fail when I don't generate HTTP_FRAME_IN_THE_WRONG_PLACE?