Subject: QUIC error codes -- too many *and* too few

From: "Aron ." <[email-masked]>
Date: Wed, 22 Mar 2017 13:50:38 -0400

Dear QUICsters,

I believe that the QUIC protocol specification goes overboard in trying to
have an error code for each error condition.  Of course, the roots of this
are historic: since both first client and server use the same code base, it
makes sense to enumerate all possible errors to facilitate debugging.  (An
error code like QUIC_MAYBE_CORRUPTED_MEMORY is a good example of this.)
However, as the number of QUIC implementations grows, a list of errors this
long and this specific is, I think, ill-advised.

My copy of *HTTP: The Definitive Guide (O'Reilly, 2002)* lists a
grand total of eighteen 400-level codes.  15 years later, Wikipedia's list
of HTTP status codes
<https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_errors>
has twenty-eight.  draft-ietf-quic-transport.md
<https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-transport.md>
has about sixty.  What is the client to do with these error codes?  It can
probably not do much more than log them.

On the server side, finding a matching error code for an error condition
would probably be a difficult task, especially if the implementation folds
several checks into one.  Other error codes are potential information
leaks, such as some crypto-related codes.

In regards to having too few error codes, it would be useful to have two
catch-all error codes (like HTTP 400 and 500), one for client errors and
one for server errors, which could be used (something like a MAY in the
spec?) when an appropriate error code does not exist.

  An aspiring QUIC implementer.

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 22 Mar 2017 14:26:57 -0700

Hi Aron,

Yes, this is definitely an issue we want to address going forward. Issue 211
<https://github.com/quicwg/base-drafts/issues/211> was filed for exactly
this.

- jana

On Wed, Mar 22, 2017 at 10:50 AM, Aron . <[email-masked]> wrote:

> grand total of eighteen 400-level codes.  15 years later, Wikipedia's
> list of HTTP status codes

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Mar 2017 08:43:28 +1100

If anyone wants to come up with a proposal that rationalizes what we
have, that would be very welcome.  I did that for the TLS draft, which
now has just three error codes, but that was easy because TLS provides
its own well-established error signaling mechanism.

Someone who wanted to help here would have to go through the draft and
find those error codes that are actually used by the specification.
Then from the remainder, either delete or find justification for each.
After that, it might pay to collapse error codes that are too similar.
I suspect that we will find the list is much shorter when we are done.

On 23 March 2017 at 08:26, Jana Iyengar <[email-masked]> wrote:
> was filed for exactly this.
>
> - jana
>
>> My copy of HTTP: The Definitive Guide (O'Reilly, 2002) lists a grand total
>> of eighteen 400-level codes.  15 years later, Wikipedia's list of HTTP
>> status codes has twenty-eight.  draft-ietf-quic-transport.md has about
>> sixty.  What is the client to do with these error codes?  It can probably
>> not do much more than log them.
>>
>> several checks into one.  Other error codes are potential information leaks,
>> such as some crypto-related codes.
>>
>> catch-all error codes (like HTTP 400 and 500), one for client errors and one
>> for server errors, which could be used (something like a MAY in the spec?)
>> when an appropriate error code does not exist.
>>