Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fetch keepAlive inflightKeepaliveBytes errors cannot be handled #1816

Open
DerGernTod opened this issue Mar 24, 2025 · 0 comments
Open

fetch keepAlive inflightKeepaliveBytes errors cannot be handled #1816

DerGernTod opened this issue Mar 24, 2025 · 0 comments

Comments

@DerGernTod
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants