Error logging for subresources

[igrigorik]

From: http://lists.w3.org/Archives/Public/public-web-perf/2014Jul/0095.html

ttuttle@: I'd like to figure out a way to support logging errors involving requests that were not top-level navigations. There are plenty of other things that can fail to load that the site owner might not necessarily have control over. (For example, Facebook might want to know when parts of their social plugin fail to load, even if they are not hosted on a site where Facebook can add an error handler.)

aheady@: I completely agree, and this was one of my largest goals with this spec. But it basically became a CORS problem and we agreed that it likely wasn’t going to be solved in this first round. So as not to delay getting top-level errors, getting a foothold on the problem, we went ahead without CORS level errors. I really hope we can change that in the long run. It is very compelling. I’d love to discuss that and sort it out.

ttuttle@: What was the issue? Accessing them with JavaScript? I'd like to arrange things so that only the origin that the subresource is being requested from can request monitoring/logging. If Facebook has a script embedded in my blog, I can't see anything extra about Facebook besides what the platform already gives me, and they can't see anything extra about me, just the result of the fetch against their own servers.

I agree that we should expose error data for subresources.

If we have CORS concerns, we should simply re-use the TAO logic from Resource Timing - i.e. copy/paste with same header, etc.

[igrigorik]

Based on discussion on our conf call [1], the recommendation was to expose failed resource fetches in Resource Timing instead - i.e. you won't get the error name, but you can inspect the timestamps to see how far the fetch got.

Closing this, will open a new bug against Resource Timing.

[1] http://lists.w3.org/Archives/Public/public-web-perf/2014Oct/0055.html