Clarify which network errors create a resource timing entry

[noamr]

It's not clear from the spec/implementation which errors should or shouldn't create an RT entry.
CORS errors explicitly don't, though in the original Resource Timing spec they should create an RT entry. However, the discrepancy between different error types might create a case where it could be detected whether an error is of CORS nature, which should be avoided.

See #1202 (review)

[noamr]

See w3c/resource-timing#12

[noamr]

See comment: #1202 (comment)

[noamr]

One simplified option would be that the caller is responsible to report the RT entry in case of a network/CORS error.
The caller (e.g. a script tag) knows when the call to FETCH was made and when it has received an error, so it could report those timing as the start/end time to resource timing, without exposing anything about the connection info.

Not sure if we want to expose connection info and other things when there was a network error, probably not.

[annevk]

Yeah, if we report network errors we want to act as if they are cross-origin and lack TAO. We could store the relevant information on the network error for the caller (it's a type of response after all, albeit rather special). That's my option 1.

Option 2 would be reporting all responses that are not network errors.

Option 3 would be reporting all responses that the caller considers actionable (i.e., would exclude non-2xx in case of <script>).

They are not in a preference order. I don't really know what would help web developers the most.

Whichever option we decide to go with should not provide a new information channel.

cc @yoavweiss @npm1 @rniwa @bdekoz @sefeng211

[annevk]

I noticed another problem, due to network errors having an empty URL list, finalize and report timing always returns early. So as currently specified option 1 does not work.

[npm1]

We briefly discussed this in the WebPerf WG call today, it wasn't clear to me if there's a use case for entries from network errors. Also @nicjansma pointed out that there's already overlap with the Reporting API.

[annevk]

You mean with https://w3c.github.io/network-error-logging/? That's true. If everyone is fine to align on no entries for network errors, let's do that.

[noamr]

@yoavweiss what's needed to reach consensus/conclusions on this?

[nicjansma]

While there is overlap with the Reporting API (Network Error Logging), I think there's value in keeping network-level errors, since the ergonomics and delivery are different (e.g. out-of-band reports). If we're reporting network-level errors via Reporting API, is there still concern about surfacing them through ResourceTiming as well (which is what most browsers are doing today)?

This is a lot of what the issue w3c/resource-timing#12 was about, getting consistency on network-level and non-200 errors among the browsers.

I just did a quick refresh to see where browsers are today, and except for Safari, network-level errors are reported everywhere else:

w3c/resource-timing#12 (comment)

What we have today is aligned closer with @annevk 's Option 1, "... to act as if they are cross-origin and lack TAO". The entries exist (except in Safari), but have all breakdown timestamps zero'd. Just fetchStart/responseEnd/duration are set.