Re: [whatwg/fetch] Attach timing info and URL to network errors, and report for fetch API (#1311)

> > I'm not super familiar with this, but it sounds like this could be non-trivial to implement; is that right? In this case, are other implementors are also willing to implement this change? I don't recall very strong use cases for the error entries on the call (and there is already NEL). Don't mean to ask to revisit this but we should make sure browsers are going to align on whichever fix we choose to spec.
> 
> I think browsers should align on either this or on also not reporting RT entries for CORS failures, which is something that's currently different between implementations and exposes cross-domain information.

@npm1 I checked Chrome & Firefox now and it does report network errors as RT entries for a lot of common network errors (CORS, time out, connection refused, etc). Safari does not report any of those.

One difference from this spec PR is that errors (and successes) are only reported for HTTP(S) fetches, which is perhaps a good idea to add to the spec and remove non-HTTP(S) tests from the WPT PR.

So to summarize there is no current security issue in implementations, but implementations are incompatible. Currently Safari is conforming to the spec (not reporting network errors to timeline) and Firefox/Chrome are not, until this PR and subsequent reporting PRs are accepted.

/cc @yoavweiss

 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/1311#issuecomment-968074302