Re: [whatwg/fetch] New Proposal: Fetch retry (Issue #1838)

annevk left a comment (whatwg/fetch#1838)

I don't think sending new request headers for no-CORS is okay. We generally decided not to add new no-CORS capabilities or endpoints. I don't think this feature is important enough to subvert that.

And even for CORS we have limits on place on the headers that can be transmitted without preflight and we generally don't add new headers, even if they are browser-controlled (except if they are prefixed with `Sec-`).

Some more feedback:

- `retryAfterUnload: true` It's not clear to me why this is needed. Can't this be derived from `keepalive` or `fetchLater()`? When do you want `keepalive`, but no retries?
- I'm fairly convinced we need to move to the model suggested above where you either get a response (early) or you get a network error at `maxAge`, but you'll never get a network error early. This reveals the least amount of information and allows user agents to optimize the most when it comes to battery and such.
- `maxAttempts` `unsigned long long` seems a bit big for this? Do we want the specification to enforce a maximum value and throw?
- Should we give delay and its multiplier default values?

Have you looked at how existing JavaScript libraries are solving this and what their APIs look like? And what APIs look like in other networking environments?

Would be interesting to hear from @jasnell and @lucacasonato if this would also work for Node and Deno.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1838#issuecomment-3068061166
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1838/3068061166@github.com>