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.
