On Fri, Oct 17, 2014 at 9:16 AM, Ben Maurer <ben.mau...@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
