Re: Rationalise HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME

[Lucas Pardue <[e-mail]>]

I also overlooked something, HTTP_MALFORMED_FRAME was replaced with
HTTP_FRAME_ERROR which is presently defiend for use when a frame layout is
wrong, or its size is wrong.

Is the case of syntax error sufficiently unique from used incorrectly error
that HTTP_WRONG_STREAM and HTTP_UNEXPECTED_FRAME  currently articulate?
There is some overlap, so an more extreme step would be to merge them into
HTTP_FRAME_ERROR.

I'm undecided on the best course of action here, I don't even think
preparing candidate PRs will help the conversation much because of the
nature of the issue.

On Thu, Aug 8, 2019 at 8:16 PM Mike Bishop <[e-mail]> wrote:

> 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?
>
>
>