Description
What is the issue with the Fetch Standard?
The spec is very clear about what should happen when inflightKeepaliveBytes exceed the limit of 64kib:
If the sum of contentLength and inflightKeepaliveBytes is greater than 64 kibibytes, then return a network error.
This means that the user can't differentiate between requests that failed because the inflightKeepaliveBytes have been exceeded, or other network errors. Usually, it doesn't make sense to retry a request that resulted in a NetworkError, but for fetch keepalive it does make sense.
Keepalive can be used by multiple third party tools to report e.g. performance data, each of them might be racing to be the first not to fall into the limit. But once the fetchGroup is empty again, why not allow the user to try it again if the request error'd because of exceeding inflightKeepaliveBytes?
With the current spec, it is not possible to differentiate between network errors that were triggered because of an actual network issue, or those triggered by a self-issued client limitation.
At the moment, in chromium and webkit the fetch call rejects with a TypeError (message for webkit: "Load failed", for chromium: "Failed to fetch"), which is also rather unspecific and could be any arbitrary error.
I think it makes sense to provide more information here to allow the user to recover. I'd be happy to hear opinions.