Fetch: Term 'network error' conflicts with NEL, and is really a response.

[clelland]

Originally from https://github.com/w3c/network-error-logging/issues/115:

Both Fetch and Network Error Logging define "network error", in different ways. NEL's should probably be spelled differently.

I would argue that Fetch's definition of network error more accurately describes a response returned as the result of an error than an actual error.

Could we change the name of the term in Fetch, to disambiguate the two?

[annevk]

Fetch's network error encompasses all network errors (and intentionally hides details). It's modeled as a response as a caller convenience. It also seems rather unlikely it could be changed given the numerous dependencies.

[clelland]

I would propose 'network error response' as a more precise term for fetch -- for convenience or otherwise, that seems to be what it actually is. Fetch certainly does have more inertia, though; I expected that the widespread usage in other specs would make it the more difficult of the two to change.

[annevk]

Can you give me an example of a network error that NEL covers that Fetch's network error does not?

[annevk]

(It actually seems to me that NEL should use Fetch's network error as a primitive and not create a duplicate that isn't part of the fetching pipeline.)

[clelland]

You may be right that NEL should tie in to Fetch somewhere (given that Fetch's 'network error' does hide a lot of details that NEL tries to report on, I expect that it may have to hook in somewhere else). I wasn't arguing that they cover different sorts of errors, though.

The problem is just that we have two specs defining the term "network error", to represent two different things, and one of them should probably change, so that there's no ambiguity.

NEL uses the term 'network error' to refer to the actual error condition that may trigger a report. (The report isn't called an error; the error is something that happens at the network). Fetch is using the same term to refer not to the error condition itself, but to the response object returned as a result of an error.

That's why I was suggesting changing the Fetch name -- we'd end up having the underlying network condition be called a "network error" (wherever that ends up being defined), and that condition can cause a network error response to be returned by Fetch, and could also cause a network error report to be sent by NEL.

[jyasskin]

The need to rebase NEL on Fetch is mentioned in https://github.com/w3c/network-error-logging/issues/101.

[annevk]

I think that if we wanted to expose details of network errors we would put those on network error, in a new field. And NEL then has special privileges to look at that field. NEL wouldn't have a separate channel from the fetching layer to the outside.