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

[Martin Thomson <[e-mail]>]

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 <[e-mail]> wrote:
> Hi Aron,
>
> Yes, this is definitely an issue we want to address going forward. Issue 211
> was filed for exactly this.
>
> - jana
>
> On Wed, Mar 22, 2017 at 10:50 AM, Aron . <[e-mail]> wrote:
>>
>> 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 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.
>>
>> 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.
>>
>