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 >>> >>> 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/CAM0wra_PpwV676Pj%3DK7tgOHOOB7C2D%2BWF-B6t6O4Mk5YAqUaQg%40mail.gmail.com.
