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

[Jana Iyengar <[e-mail]>]

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