I'm just curious, is there a reason this is going through WICG instead of the WHATWG stages process?
https://whatwg.org/stages Given its proposing to change the fetch spec, I would have thought it would be in that process. Are there any past or ongoing discussions in fetch spec issues? On Wed, Jun 25, 2025 at 3:00 AM Rakina Zata Amni <rak...@chromium.org> wrote: > Contact emailsrak...@chromium.org > > Explainerhttps://github.com/explainers-by-googlers/fetch-retry/tree/main > > SpecificationNone > > Design docs > > https://docs.google.com/document/d/1C9lAn3tqXsrjxiid1qCC9qSL7jfA1PZdoo2lgL8L5Pw/edit?tab=t.0 > > Summary > > Allow web developers to indicate that a fetch() request should be retried, > to have a greater guarantee on it being reliably sent, even if the network > is flaky. This is especially important for keepalive fetches, where the > request might outlive the document, which can no longer watch for its > failure and do manual retry. We intend to only support this for keepalive > fetches for now because of implementation simplicity, and also the fact > that all the use cases would benefit from being keepalive first. > > > Blink componentBlink>Loader > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ELoader%22> > > Motivation > > fetch() requests can fail due to transient network errors. Manual > JavaScript retries are complex and impossible to be done after page unload > (e.g. for keepalive fetches), causing data loss for critical/high-value > beacons. This proposal introduces a configurable, browser-managed retry > mechanism within fetch(). It allows web developers to indicate that a > fetch() request should be retried, to have a greater guarantee on it being > reliably sent, even if the network is flaky. > > > Initial public proposalhttps://github.com/WICG/proposals/issues/217 > > TAG reviewNone > > TAG review statusPending > > Risks > > > Interoperability and Compatibility > > None > > > *Gecko*: No signal > > *WebKit*: No signal > > *Web developers*: Positive > Internal/Google developers are interested in origin trial. > > *Other signals*: > > Security > > Resource Exhaustion: Malicious or misconfigured sites could attempt to > trigger excessive retries, potentially impacting network resources or > target servers. Mitigation relies on browsers enforcing strict, reasonable > limits on maxAttempts and maxAge, alongside implementing backoff delays. > Information Leakage (Retry-Attempt Header): The proposed Retry-Attempt > header explicitly reveals the retry state of a request to the target server > and any intermediaries. While useful for debugging and server > logic/deduplication, it does constitute information disclosure about the > client's network behavior for that request, but the risk is likely low. > Timing Attacks/Information Leakage: The timing patterns of retry attempts > could theoretically leak some information about network conditions. This is > unlikely to provide substantially more information than can already be > inferred by observing standard network request timings and failures. > Additionally the browser will add random delays/jitters as well. The risk > is considered low. > > > WebView application risks > > Does this intent deprecate or change behavior of existing APIs, such that > it has potentially high risk for Android WebView-based applications? > > None > > > Debuggability > > None > > > Is this feature fully tested by web-platform-tests > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?No > > Flag name on about://flags > > Finch feature nameFetchRetry > > Requires code in //chrome?False > > Tracking bughttps://crbug.com/417930271 > > Estimated milestones > DevTrial on desktop 138 > DevTrial on Android 138 > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/5181984581877760?gate=5075324035137536 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r6QFoqcmdoEMeG4JKJXGLqvGW%2BMr-UZj%2Br6HrQ%3DTNqKYQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r6QFoqcmdoEMeG4JKJXGLqvGW%2BMr-UZj%2Br6HrQ%3DTNqKYQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMhvHK3tBZF%3DGvwdOMx9R9aFbT_-Deb_RweWqjTPbx5Gwg%40mail.gmail.com.
