Ok. I think this will be quite iterative and we'll  try to figure out the
exact set of customizations and optimizations during the origin trial, so
if we can just request 6 milestones from the start maybe that's ideal
(139-144). Thanks!

Regards,

Rakina

On Fri, Jul 18, 2025, 02:07 Mike Taylor <miketa...@chromium.org> wrote:

> 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/CACPC1r54nPFm6-exTjgNcO%2BwKFKsEhKWhaqiq7DiRRz6F_uQXg%40mail.gmail.com.

Reply via email to