You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 fetchkeepalive 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.
The text was updated successfully, but these errors were encountered:
What is the issue with the Fetch Standard?
The spec is very clear about what should happen when
inflightKeepaliveBytes
exceed the limit of 64kib: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 aNetworkError
, but forfetch
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 exceedinginflightKeepaliveBytes
?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 aTypeError
(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.
The text was updated successfully, but these errors were encountered: