W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2013

On using POSIX error codes for logging

From: Daniel Austin <daniel_b_austin@yahoo.com>
Date: Wed, 22 May 2013 10:03:40 -0700
To: <public-web-perf@w3.org>
Message-ID: <01e101ce570e$4f68ccf0$ee3a66d0$@yahoo.com>
Hi Team,


               In our meeting 2 weeks ago, Arvind had proposed that we might
use the POSIX error codes as a canonical list of network-related errors in
our specs, as a means of avoiding creating our own list of errors as I've
proposed. (We're referencing the IANA list of HTTP codes.) Unfortunately,
after doing some investigation, I don't think this approach will work.
Here's why:


*        The POSIX error codes [1] are not numbered consistently. Each
system can supply its own numbers (or not). These are typically surfaced in
errno.h - here's an example: 

#define ECONNRESET 104  /* Connection reset by peer */


In order to make these codes useful when exposed by a layer 7 client, we
would risk duplication and confusion in the numbering. The POSIX spec itself
does not provide normative numbers.


*        Many of the POSIX errors simply don't apply to our layer 7 client
and would never be exposed - 

[ENOTSOCK] The socket argument does not refer to a socket

If we reference the POSIX spec by reference, we would need to be able to
distinguish the ones that apply from those that don't. The text string
identifier might be used for this, but it seems very difficult and confusion


I continue to think that we should identify a canonical subset of the POSIX
errors that are suitable for exposure at layer 7, provide a reasonable
numbering system, and list them in the spec. I also think we should preserve
the detailed error messages. I propose that we adopt the test string
identifiers from POSIX as much as possible for consistency, and list POSIX
as a normative reference along with IANA.


This was a really good idea, but it doesn't work for our purposes, IMHO. 






[1] http://pubs.opengroup.org/onlinepubs/9699919799/

Received on Wednesday, 22 May 2013 17:04:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:35 UTC