LGTM3 On Wed, Jul 2, 2025 at 7:26 AM Daniel Bratell <bratel...@gmail.com> wrote:
> LGTM2 > > /Daniel > On 2025-07-01 09:36, Yoav Weiss (@Shopify) wrote: > > LGTM1 for a slow roll-out, given the fact that "breakage" may most likely > present itself as extra server load. > > On Tue, Jul 1, 2025 at 5:42 AM Domenic Denicola <dome...@google.com> > wrote: > >> We're optimistic that this will result in no "breakage". The Purpose >> header was not reliable (e.g., it was Chromium only, and it was only sent >> by some types of preloads). Sec-Purpose has been in place for a long time >> now, and is the one documented everywhere, that works in Firefox, etc. >> >> That said, it's hard to get visibility into what server operators are >> doing with headers. Probably the most common use would be denying some >> preload traffic. In that case, removing it might cause the server to >> perform more serving operations than they previously did, if the server is >> not also checking Sec-Purpose. But in the theoretical worst case, the >> server could be varying its content on the header, which would result in >> users seeing different responses. (This seems very unlikely, as sending >> different responses for preloads vs. normal loads is a very bad idea in the >> first place.) >> >> We've generally found that most open-source code checks a large variety >> of headers, including the standard Sec-Purpose, and so won't be affected. >> See, e.g., some of the results from this GitHub code search >> <https://github.com/search?q=Sec-Purpose+prefetch+language%3AJava+&type=code>. >> (Here's an attempt >> <https://github.com/search?q=prefetch+AND+%5C%22Purpose%5C%22+AND+NOT+Sec-Purpose+language%3AJava+&type=code&p=4> >> at >> the inverse code search, which doesn't show any cases of only checking for >> Purpose, but I'm not sure the search is very well-crafted.) Unfortunately >> this isn't something we can use-count, so I think the best approach here is >> to just roll it out and be prepared to kill-switch if something unexpected >> shows up. >> >> On Tue, Jul 1, 2025 at 12:45 AM Yoav Weiss (@Shopify) < >> yoavwe...@chromium.org> wrote: >> >>> Do y'all have any estimate on potential breakage, what may be its scale >>> and what it may look like? >>> >>> On Thursday, June 26, 2025 at 8:43:52 PM UTC+2 Chromestatus wrote: >>> >>>> Contact emails steven...@microsoft.com >>>> >>>> Explainer https://github.com/whatwg/fetch/pull/1576 >>>> >>>> Specification >>>> https://wicg.github.io/nav-speculation/prerendering.html#interaction-with-fetch >>>> >>>> Design docs >>>> https://fetch.spec.whatwg.org/#ref-for-http-sec-purpose%E2%91%A0 >>>> >>>> https://wicg.github.io/nav-speculation/prefetch.html#ref-for-http-sec-purpose >>>> >>>> Summary >>>> >>>> Now that prefetches and prerenders are utilizing the Sec-Purpose header >>>> for prefetches and prerenders, we will move to remove the legacy Purpose: >>>> prefetch header that is still currently passed. This will be behind a >>>> feature flag/ kill switch to prevent compat issues. This will be scoped to >>>> speculation rules prefetch, speculation rules prerender, <link >>>> rel=prefetch>, and Chromium's non-standard <link rel=prerender>. >>>> >>>> >>>> Blink component Blink>Loader >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ELoader%22> >>>> >>>> TAG review Not filed as this is a minor change of unspec'ed UA >>>> behavior for an existing feature. (Can start a review if recommended) >>>> >>>> TAG review status Not applicable >>>> >>>> Risks >>>> >>>> >>>> Interoperability and Compatibility >>>> >>>> As commented at notes on Firefox and Safari, each browser uses >>>> non-standardized header name that is not aligned with CORS spec. This >>>> change will introduce better interoperability and compatibility for a long >>>> term. >>>> >>>> >>>> *Gecko*: Positive ( >>>> https://github.com/mozilla/standards-positions/issues/1259) >>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1965945 They currently >>>> already pass the web platform tests for standardizing on using Sec-Purpose >>>> for prefetch. >>>> >>>> *WebKit*: Support ( >>>> https://github.com/WebKit/standards-positions/issues/114) Positive as >>>> part of aligning on <link rel=prefetch> >>>> >>>> *Web developers*: No signals >>>> >>>> *Other signals*: >>>> >>>> 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 >>>> >>>> >>>> Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)? Yes >>>> >>>> Yes, since it affects <link rel=prefetch> which is on all platforms >>>> >>>> >>>> Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>> ? Yes >>>> >>>> >>>> https://wpt.fyi/results/preload/prefetch-headers.https.html?label=experimental&label=master&aligned >>>> >>>> >>>> Flag name on about://flags None >>>> >>>> Finch feature name RemovePurposeHeaderForPrefetch >>>> >>>> Rollout plan Will ship enabled for all users >>>> >>>> Requires code in //chrome? False >>>> >>>> Tracking bug https://issues.chromium.org/issues/420724819 >>>> >>>> Estimated milestones >>>> Shipping on desktop 139 >>>> Shipping on Android 139 >>>> Shipping on WebView 139 >>>> >>>> Anticipated spec changes >>>> >>>> Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure of >>>> the API in a non-backward-compatible way). >>>> None >>>> >>>> Link to entry on the Chrome Platform Status >>>> https://chromestatus.com/feature/5088012836536320?gate=5120193717862400 >>>> >>>> Links to previous Intent discussions Intent to Prototype: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6836470b.2b0a0220.33c819.0963.GAE%40google.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/CAOmohSKKakt%2Bk%2BePB209anKsh9Mzar-PjLDvChJC_K8kLrQ5Hw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKKakt%2Bk%2BePB209anKsh9Mzar-PjLDvChJC_K8kLrQ5Hw%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/3aa765b6-0b41-438f-978d-64658d6a0522%40gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3aa765b6-0b41-438f-978d-64658d6a0522%40gmail.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/CAOMQ%2Bw__-f0XsC%2B4L%2B3txeo3%2ButrCgDF_sCsauyMts%2BVp1tEKg%40mail.gmail.com.
