W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

Re: Conflicting MUST in RFC7540

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 24 Jan 2019 09:12:37 +0100
To: Martin Thomson <mt@lowentropy.net>
Cc: ietf-http-wg@w3.org
Message-ID: <20190124081237.GA20924@1wt.eu>
On Thu, Jan 24, 2019 at 06:56:55PM +1100, Martin Thomson wrote:
> 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.

Oh I'm not giving way to this at all, however every error has the merit
to make me read the spec and wonder about the impacts of my choice. This
has allowed me to fix a high number of problems so for now I'd say it's
highly beneficial.

> > >   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).

Then we should probably suggest that stream errors should be upgraded to
connection errors when the same condition exists as a connection error in
another context.

> > 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".

I got it now.

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

No, we don't care about a stream error being emitted as long as the connection
error is emitted. It's indeed not a good idea to dictate to implementations
how they should write their code. And the stream error might already have been
queued on the wire.

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

I wholeheartly agree!

OK thus I'm going to modify my code where I check for the frame types
to report a connection error when this is required in at least one
paragraph in the spec.

Thanks!
Willy
Received on Thursday, 24 January 2019 08:13:03 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 24 January 2019 08:13:03 UTC