Re: Web Request Status Codes

On 13/04/2013, at 2:23 AM, Aaron Heady (BING) <aheady@microsoft.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%.
> 
> Given that we cannot get an allow header on a completely failed request, and that seeing the cross origin resource failures is of immense value to legitimate service operators, can the concept of the CORS allow headers be extended to include something like a cache TTL. We really expect this feature to work because we have active users that will see an error and then visit us again in a short time period which will allow us to retrieve the errors. If the cross origin allow header were honored for more than just an individual response then the user agent could already know that it's okay to see the error codes for contoso.com resources rendered on example.com. Then when an actual error occurs rendering contoso.com/ad1.js the existing cached allow header can be checked and allow example.com to see the details of the contoso.com resource error.
> 
> Basically keep all of the semantics of cross origin checks, just add an optional expires header to the tag. Or to allow complete backwards compatibility, a separate max-age header like:
> 
> Access-Control-Allow-Origin: http://hello-world.example
> Access-Control-Max-Age: 3628800
> 
> From: http://www.w3.org/TR/cors/#introduction


So, something like

  Timing-Allow-Origin-Maxage: 600

? To me, this is a lot of bytes for gathering (hopefully rare) errors. Is it too late to shorten Timing-Allow-Origin?

Just curious - has there been any discussion as to whether ResourceTiming can additionally use the presence of Access-Control-Allow-Origin to determine whether it's OK to expose cross-site info?

I can understand that we wouldn't want to *only* use this hint, as there will be cases when someone wants to allow cross-origin timing access, but not full API access. However, in the case when they want to do both, it seems like it would be a win if we could just get away with one header, instead of two. Of course, this depends upon there not being any scenario where it's undesirable/dangerous to allow timing access to someone with API access.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 15 April 2013 01:47:36 UTC