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/CAK7rkMjq%2BY7XFpGgu9zn3_H7cTX34G-%2BQnW-U7or_7gG8-vwdQ%40mail.gmail.com.
