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

rakina left a comment (whatwg/fetch#1838)

> The comment above retryNonIdempotent says PUT and DELETE are non-idempotent, but the details below say they are idempotent.

Oh oops, sorry, that was a mistake. In Chromium [impl](https://source.chromium.org/chromium/chromium/src/+/main:net/http/http_util.cc;l=375;drc=e18a32c4b96ad2b2c2f50195936594d1f7c4f62a) at least {PUT, DELETE} are idempotent and {GET, HEAD, OPTIONS, TRACE} are safe and idempotent. We can add a "safe" toggle as well, although I'm not sure how useful that is. In any case this retry feature is an explicit opt-in, and the caller knows what method it's using, so really it's just a double-checking mechanism to make sure the users know the risk of non-idempotent methods? (But happy to just add more safe-guards if that seems like a good idea).

> Currently Safari retries safe (GET/HEAD/OPTIONS) methods automatically in some situations (we cannot retry once we process and deliver the response header). 

 This is interesting, is this just an automatic optimization? Does that do anything special related to the cases mentioned in this thread, e.g. redirects, no-cors, having same-origin/NIK documents around?



BTW, on https://github.com/whatwg/fetch/issues/1838#issuecomment-3057763297,  I looked at `no-cors` a bit more and it seems like even in that mode, even though responses are opaque, it's still possible to know if a network error happened, since that will show up as a promise failure on the fetch. So retrying even with `no-cors` seems OK, since it's not really different from what scripts can do manually anyways (by e.g. catching the error and re-attempting the fetch manually).

I'm also still not sure if there's anything problematic with sending the `Retry-Attempts` and `Retry-GUID`, even after cross-origin redirects. It seems like the motivation to strip some headers on cross-origin redirects is if it's related to authorization, or if it's something that a script can inject to the request (e.g. custom headers). But the `Retry-Attempts` and `Retry-GUID` are added by the browser, and the information revealed there is solely for identifying the fetch itself across retries (the ID) and differentiating the attempts (the attempts count) and the script can't control anything about the values there.

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

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