Thanks, I've created an issue <https://github.com/whatwg/fetch/issues/1838> in whatwg/fetch for this proposal to get wider feedback on this. LMK if I need to do anything else!
On Thu, Jun 26, 2025 at 10:06 PM Ben Kelly <wanderv...@chromium.org> wrote: > Thanks. I guess I was most interested in seeing if Anne had a take on > this yet, so I was just looking around for a fetch issue or something when > this question occurred to me. > > On Thu, Jun 26, 2025 at 2:17 AM Domenic Denicola <dome...@chromium.org> > wrote: > >> I think you should do whichever you prefer. We've found the WHATWG Stages >> process is most useful when the person driving the feature (you) wants to >> get strong community feedback on how well their proposal is advancing >> through the stages. But you can also add features to WHATWG specs "the >> usual way", by just posting a PR and bugging people for reviews and >> standards-positions and so on, without the forcing function of stage >> advancement. >> >> Some discussion of this is at >> https://blog.whatwg.org/staged-proposals-at-the-whatwg . >> >> On Thu, Jun 26, 2025 at 3:11 PM Rakina Zata Amni <rak...@chromium.org> >> wrote: >> >>> Hi, there's no reason actually, it's just WICG is what I was familiar >>> with and thought all proposals should go there, sorry for the confusion :) >>> >>> So if we have to go with the WHATWG process, what would that require? >>> Should I start a new issue in whatwg/fetch >>> <https://github.com/whatwg/fetch/issues>, or something else? >>> Discussions on this feature have all been Google-internal (since the use >>> cases came up internally), but we definitely want to discuss the feature >>> externally too. >>> >>> FWIW I've chatted with @Domenic Denicola <dome...@chromium.org> about >>> what parts of the Fetch spec would probably need to be changed for this, so >>> we have some plans for the spec (although not actual PRs yet). >>> >>> On Wed, Jun 25, 2025 at 10:21 PM Ben Kelly <wanderv...@chromium.org> >>> wrote: >>> >>>> 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 >>>>> >>>>> Explainer >>>>> https://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/CACPC1r7%3DU53yMf_-Bm3a%3D8g8h%3DEcjG2NC-_vEsk734CgPx4-oA%40mail.gmail.com.
