Re: Web Request Status Codes

Exposing HTTP status codes exposes a lot of information that hasn't been
exposed before. For instance, there are codes that explicitly reveal the
existence of a proxy and whether or not a resource is cached. We haven't
exposed this sort of information before.

Before getting too far ahead of ourselves, I think we need to have a
thorough security and privacy review about whether it's safe to expose this
level of information. Otherwise, we're just wasting time discussing this.

Separately, note that the DNS and TCP (and possibly many HTTP) errors are
useless for cross-origin requests, because there's no way to determine if
logging is allowed.

James


On Mon, Apr 8, 2013 at 3:48 PM, Austin,Daniel <daaustin@paypal-inc.com>wrote:

>  Hi Team,****
>
>                 I’ve attached to this email an HTML file with the current
> list of Web Request Status Codes. This list includes all of the status
> codes that I’ve been able to track down, with some exceptions. There are a
> great many of them. Here’s a breakdown of the process and the decisions I
> made to produce the current list:****
>
> **·         **Some status codes were omitted for being ridiculous (418,
> 420)****
>
> **·         **Some status codes returned by existing servers but not part
> of any RFC are still listed in red – I don’t think they belong here
> (possibly with the exception of 509) but I’ve left them in for discussion
> purposes.****
>
> **·         **Non-HTTP status codes have been added. There are a lot of
> them (around 40). Since RFC 2616 clearly specifies that HTTP status codes
> have 3 digits, I’ve begun the numbering for non-HTTP status codes at 1000.
> These status codes are broken down by their level in the OSI stack and
> namespaced accordingly e.g. 1207 SSL: Cipher Error as opposed to 1109 TCP:
> No route to host. There are four groups of these, namespaced as DNS:, TCP:,
> SSL:, HTTP:, and Client: . The HTTP: status codes are not currently
> included in RFC 2616 or any of the other specs, but are common errors seen
> by clients e.g. 1302 HTTP: Header malformed. Perhaps ‘HTTP server:’ is
> better?****
>
> **·         **I’ve included a key to the different RFCs that contain HTTP
> status codes. There are 13 (!) of them, and 2 status codes are in draft
> proposals, linked in the document.****
>
> **·         **For any status code not included in RFC 2616, I’ve tried to
> provide a rationale for its existence. ****
>
> **·         **Color codes: black = RFC 2616, blue = new for this spec or
> repurposed from some proprietary list, red = proprietary and doesn’t belong
> here IMHO****
>
> **·         **Sources: RFC 2616, other RFCs and drafts as listed,
> Wikipedia, Stack Overflow, MSFT sites, Compuware/Gomez, KeyNote,
> Catchpoint, Nginx, Apache****
>
> **·         **For completeness, I’ve included all status codes received
> by the client, not just the error codes. There are several that are not in
> RFC 2616.****
>
> **·         **I took the liberty of repurposing some
> existing-but-nonstandard codes and renumbering them for our purposes. I’ve
> tried to indicate the source e.g. (Nginx)****
>
> Here’s the next steps as I see them:****
>
> **·         **Agree on a more-or-less final list of status codes, correct
> any omissions or duplicates****
>
> **·         **Move this table into Jatinder’s spec (or maybe a separate
> Note?)****
>
> This task took considerably more time and effort than I had expected. Who
> knew there were so many status codes ? ****
>
> Regards,****
>
> D-****
>
> ** **
>