Thanks Rakina! On Fri, Jun 27, 2025 at 9:23 AM Rakina Zata Amni <rak...@chromium.org> wrote:
> 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/CAK7rkMjbvaDqxWhHTWdphQoieU3sSWt6rwawuj6tQKFpdZs%2B3g%40mail.gmail.com.
