Thanks - you can request an OT for up to 6 milestones <https://www.chromium.org/blink/launching-features/#:~:text=An%20initial%20origin%20trial%20or%20experiment%20for%20a%20feature%20may%20only%20run%20for%206%20milestones%20of%20Chromium>, but you will know better what makes sense for your feature. 3 might make sense, or more. Please let us know. :)

On 7/16/25 7:07 p.m., Rakina Zata Amni wrote:
Oh sorry, I didn't realize there's a different field for OT. I'm requesting OT from 139. Not sure how many versions typically OTs should last for (3 milestones)?

On Thu, Jul 17, 2025 at 2:57 AM Mike Taylor <miketa...@chromium.org> wrote:

    Could you clarify which milestones you're requesting to experiment
    on? (Right now it just shows DevTrial on 139)

    On 7/16/25 11:31 a.m., Chromestatus wrote:


            Contact emails

    rak...@chromium.org, m...@chromium.org


            Explainer

    https://github.com/explainers-by-googlers/fetch-retry/tree/main


            Specification

    None


            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 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 component

    Blink>Loader
    
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ELoader%22>



            TAG review

    None


            TAG review status

    Pending


            Risks



            Interoperability and Compatibility

    None



    /Gecko/: No signal

    /WebKit/: No signal (https://github.com/whatwg/fetch/issues/1838)
    Safari devs have responded in the proposal thread and gave
    constructive feedback and doesn't seem to be opposed.

    /Web developers/: Positive
    (https://github.com/whatwg/fetch/issues/1838#issuecomment-3035074583)
    Internal developers interested in origin trial. External
    developers have proposed a similar feature/made libraries similar
    to this, and generally seems interested in the proposal thread.

    /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. 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 ensure that the errors are not exposed to the script until
    max age set in the retry options is reached, regardless of
    whether a retry happened or not, and only the latest error is
    exposed instead of all attempts.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



            Goals for experimentation



            Ongoing technical constraints

    None



            Debuggability

    None



            Will this feature be supported on all six Blink platforms
            (Windows, Mac, Linux, ChromeOS, Android, and Android
            WebView)?

    Yes


            Is this feature fully tested by web-platform-tests
            
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?

    No

    This feature is essentially invisible to the script initiating
    the fetch since it can't know if a retry happened or not.



            Flag name on about://flags



            Finch feature name

    FetchRetry


            Requires code in //chrome?

    False


            Tracking bug

    https://crbug.com/417930271


            Estimated milestones

    DevTrial on desktop         139
    DevTrial on Android         139



            Link to entry on the Chrome Platform Status

    https://chromestatus.com/feature/5181984581877760?gate=5140384199737344



            Links to previous Intent discussions

    Intent to Prototype:
    
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACPC1r6QFoqcmdoEMeG4JKJXGLqvGW%2BMr-UZj%2Br6HrQ%3DTNqKYQ%40mail.gmail.com



    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/6877c5df.170a0220.a2b55.0311.GAE%40google.com
    
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6877c5df.170a0220.a2b55.0311.GAE%40google.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/70e31357-56f7-402c-a1c4-c5fc22fcf55c%40chromium.org.

Reply via email to