Re: Conflicting MUST in RFC7540

[Martin Thomson <[e-mail]>]

On Thu, Jan 24, 2019, at 18:49, Willy Tarreau wrote:
> I've found a few other ones in the past that I had to address so that
> h2spec doesn't complain, I was fine with doing so because either choice
> was OK. I really think that the problematic ones are for these few frames
> which affect the compression state.

Ahh, I don't think that we should be subject to the tyranny of the interop suite in this case.  If you were responding to a genuine error condition with the prescribed error code, you should be conformant.

> >   This specification or its extensions could define error conditions that
> >   result in conflicting requirements about which error code is sent when
> >   multiple errors are present.  Implementations MAY respond to the first
> >   error condition that they detect.  Consequently, if multiple errors are
> >   present, different implementations could produce different error codes.
> >   However, a connection error MUST NOT be suppressed as a result of reporting
> >   a stream error.
> 
> Do you imply by the last sentence that both a stream error and a connection
> error should be sent in this case ? 

Maybe.  The idea is not to constrain the error reporting so that both have to be juggled and balanced.  You should be able to report the stream error then the connection error, or if you encounter the connection error first, just report that.  (Or report the stream error as a connection error, which is also permitted).

> If so, it sounds less natural to me
> because it could significantly complicate error paths depending on the
> implementations. What about something like this :
> 
>     When a violation could result either in a stream error or a connection
>     error depending on where the condition is matched, the connection error
>     has precedence and must be applied.

Yeah, what you have is probably clearer, but I would simply say "the connection error MUST be reported".  The notion of precedence doesn't really matter here - that might imply a requirement to suppress the stream error, which I don't think is a good idea.  Error reporting needs to be uncomplicated and direct, and any implication of having to bundle them up so you can sort them out encourages sloppy code on critical paths that don't often get enough exercise in the real world.