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

rakina left a comment (whatwg/fetch#1838)

> Isn't https://github.com/whatwg/html/issues/10997 already addressing the use-case of "data loss for critical beacons"? I don't see that proposal (also by Google) or [its explainer](https://gist.github.com/domenic/c5bd38339f33b49120ae11b3b4af5b9b) mentioned in https://github.com/explainers-by-googlers/fetch-retry/blob/main/README.md but I think it probably should be

Thanks for pointing that out! I think while they both are around trying to minimize "data loss of critical beacons", they are tackling different problems around that.  @domenic's [Extended Lifetime SharedWorkers](https://gist.github.com/domenic/c5bd38339f33b49120ae11b3b4af5b9b) are more about "we need to run some arbitrary operations after unload, with stricter bounded time":
- It can run arbitrary operations such as writing to storage, etc.
- It will only run once, and needs to stop quite soon after the document unload (compared to fetch retry)
- Like mentioned in [this section](https://github.com/whatwg/fetch/issues/1838#issuecomment-3019452794), when async steps are required

Meanwhile fetch retry is more about "Try to ensure that this fetch gets sent, even if it takes a while"
- It's specific to fetches
- It's meant to make the fetches more resilent to potentially transient errors, which are actually quite common.
- The retry can be triggered quite a bit after the document is unloaded, but in such a way that isn't a problem privacy wise (see below, about only retrying when a same-NetworkIsolationKey document is committed).
- The retry can also be attempted when the document is still around

So the former is more around "making sure an operation is run, after potentially some async work" while the latter is more "fetches are more resilient to transient errors and have a higher chance of reaching the server". They can work together too, e.g. we can maybe trigger a fetch with retry from the worker and that makes sure it's attempted and with a higher chance of it actually getting through.

> Especially since the main difference between this proposal and that proposal is this proposal seems to enable the very concerning bad-actor tracking raised in https://github.com/whatwg/fetch/issues/1838#issuecomment-3013757470.

Oh actually I just realized the explainer doesn't mention an important detail that might mitigate the concern here (this question also came up internally, I just forgot to update the external explainer): The fetch is only retried if a same-[Network Isolation Key](https://developer.chrome.com/blog/http-cache-partitioning#how_will_cache_partitioning_affect_chromes_http_cache) document is alive. So, technically, retries can be done by that other document if it communicates through, e.g. localStorage. Since the user has a document with the same origin / network Isolation key open, it shouldn't be a surprise privacy-wise that that document can trigger a fetch?

(I'll update the explainer with these points, and the options on not leaking the errors mentioned in https://github.com/whatwg/fetch/issues/1838#issuecomment-3019452794)

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

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