- 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 prone. 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. Regards, D- [1] http://pubs.opengroup.org/onlinepubs/9699919799/
Received on Wednesday, 22 May 2013 17:04:25 UTC