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

Re: Web Request Status Codes

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 12 Apr 2013 09:46:42 +1000
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-Id: <1E36230B-879B-41CD-8C35-8931B3435A6A@mnot.net>
To: James Simonsen <simonjam@google.com>

On 12/04/2013, at 7:00 AM, James Simonsen <simonjam@google.com> wrote:

> Third party errors are absolutely off limits unless we receive explicit permission to report them. Without succeeding with the HTTP request, we don't have that permission. Otherwise, sites can figure out which bank a user uses by requesting third party resources from all of the banks and seeing which report errors.

Agreed 100%.


> Additionally, we are concerned that our users will be fingerprinted by malicious sites. Exposing additional information makes those attacks much easier.

That's very reasonable as a position statement. However, it doesn't help decide whether to add new features, because taken at face value, we wouldn't add *any* features to the Web platform ("information" is unavoidably broad, after all).

In this instance, can you explain how adding response status codes adds potential bits to a fingerprint (assuming same-origin constraints)? I agree there could be some convoluted scheme whereby a cached, non-standard status code could add a bit or two, but that doesn't seem relevant, when you consider that a cached ETag is a much simpler, already available and more capable way to do so.


> I've requested review from the Chrome privacy and security teams. I don't think we should bother discussing Error Logging any further until everyone else does the same.

Great. When will their review be complete? Will the results be shared with the WG?  (just trying to understand the process you're proposing)

WRT the specifics of the proposal - why are we enumerating the status codes? Why not just refer to the registry <http://www.iana.org/assignments/http-status-codes/http-status-codes.xml> and report the three-digit code?

Cheers,


> 
> James
> 
> 
> On Thu, Apr 11, 2013 at 11:44 AM, Austin,Daniel <daaustin@paypal-inc.com> wrote:
> Hi James,
> 
>  
> 
>                 Thanks for the feedback. I appreciate your taking the time to look at this.  However, Iím not yet convinced that there is any privacy/security concern here. My reasoning goes like this:
> 
>  
> 
> a)      There are a large number of companies doing this already, including Google (Analytics), Yahoo! (Roundtrip and Y! Analytics), Omniture (SiteCatalyst), Mediaplex (Analytics), Compuware/Gomez (RUM), and many others. These services regularly provide collection and transport for this same data and send it upstream, often to a 3rd party (which is worse IMHO). Weíre not exposing anything that others are not already doing, weíre just institutionalizing it and giving the user some control. I can certainly see 304ís, 200 (cache) responses, and proxies in that data. Presumably these companies privacy policies already alert the user about all of this, and the user has provided consent by viewing the page. (This isnít an argument about right or wrong, but about current industry practice.)
> 
>  
> 
> b)      Users can see all of this data already, by pressing F12 or similar, so itís not concealed from the user and then exposed to others. The data isnít terribly useful to end users (unless theyíre performance geeks) but itís not secret.
> 
>  
> 
> On the cross-origin issue, I think thereís something Iím not understanding. Why would cross-origin requests not be logged by the client? For this data to be useful we need to know what happened when the page loaded, regardless of the source. If I put an analytics tag in my page, for example,  and it fails for some reason, I need to know about it, and omitting the error codes is the opposite of helping.
> 
>  
> 
> 3rd party calls are very often the source of performance problems on the page, and the client, IMHO, should provide full information about everything that happens in all the HTTP request/response cycles that went into that pageís composition. In todayís world, nearly every page published by any commercial organization is likely to have some 3rd party content.
> 
>  
> 
> The more I think about this the more I think the right path is to provide detailed information for everything and be transparent about it all.
> 
>  
> 
> Regards,
> 
>  
> 
> D-
> 
>  
> 
>  
> 
>  
> 
> From: James Simonsen [mailto:simonjam@google.com] 
> Sent: Wednesday, April 10, 2013 2:58 PM
> To: public-web-perf@w3.org
> Subject: 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-
> 
>  
> 
>  
> 
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Thursday, 11 April 2013 23:47:13 UTC

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