- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 21 Feb 2014 09:43:56 -0800
- To: Cory Benfield <cory@lukasa.co.uk>
- Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 21 February 2014 09:32, Cory Benfield <cory@lukasa.co.uk> wrote: > Agreed, but I don't believe that a free-text field is the way to do > that. If we really care about making it easy to debug PROTOCOL_ERRORs > we should be adding subcodes or increasing the number of error codes. > I would be much more enthusiastically in favour of error subcodes than > anything else. > > Now, if we want to develop a convention of assigning subcodes to > specific errors and putting them in the debug field, that's an > acceptable thing to do, but if we think that convention is useful why > not codify it? Agree. In principle. However, from hard experience on this, getting this right is a lot of work. Even if one person is willing to sit down and build a taxonomy and derive from that a more extensive list of error codes, it's hard. Primarily, it's hard to get agreement that the taxonomy is right in both structure and level of detail. People have different implementations, with different structures and what makes sense in one implementation might be completely wrong in another. Over time, I've concluded that - for standardization - providing the minimal set of error codes is best. And by minimal I mean that every code implies a different action. For PROTOCOL_ERROR, the worst of our codes, this action is "fix your broken implementation". If you can identify a case that might have a different action, please raise that as an issue.
Received on Friday, 21 February 2014 17:44:23 UTC