Re: drop "Resource Error Logging" in favor of failed fetches in Resource Timing?

On Fri, Oct 17, 2014 at 9:16 AM, Ben Maurer <ben.maurer@gmail.com> wrote:

> Note that REL does *not* provide UA-reporting infrastructure - that only
>> applies to Nav Error Logging. The assumption is that to fetch a subresource
>> you must have successfully loaded the parent page first, and if that's the
>> case, then you can ship some error code within it to listen for subresource
>> fetches and log their status appropriately - e.g. via Beacon.
>>
>
> Why not hook into the UA reporting infra provided by NEL? What would the
> JS in the parent page do more intelligently than the default UA infra.
> Failure in the JS CDN seems like a perfect use case.
>

I'm not arguing against it, just pointing out how it's spec'ed at the
moment. That said, I imagine some arguments could be:
- there may be a lot of subresource failures, client-side code can (more)
intelligently dedupe, aggregate and beacon error data
- we should focus on exposing the primitives, and let the developers
implement own reporting + retries, etc.

Not saying these are strong arguments, but that's what comes to mind. That
said, UA-reporting in REL deserves a separate discussion.

Coming back to REL vs. Resource Timing...

+ REL: provides underlying error condition (e.g. reason of TLS failure)
+ REL: allows to distinguish abandoned load vs fetch error (e.g. user hits
stop or calls abort on fetch)
+ REL: does not require setting up manual callbacks on each element +
actively monitor for new fetches (i.e. simpler and friendlier API)

ig