LGTM3 On Tuesday, May 13, 2025 at 8:22:16 PM UTC+2 Alex Russell wrote:
> LGTM2 > > On Tuesday, May 13, 2025 at 11:21:54 AM UTC-7 dan...@microsoft.com wrote: > >> LGTM1 >> >> On Monday, May 12, 2025 at 3:00:13 PM UTC-7 stev...@microsoft.com wrote: >> >>> Yes, thanks for the reminder. This is my first Intent to Ship so will >>> note this for future ones! >>> >>> On Monday, May 12, 2025 at 2:32:23 PM UTC-7 mike...@chromium.org wrote: >>> >>>> Before continuing the review, could you please request all the privacy, >>>> security, enterprise, etc bits in the chromestatus entry? >>>> On 5/12/25 2:32 PM, 'Steven Wei' via blink-dev wrote: >>>> >>>> domenic@ found the place in HTML spec that already mentioned this >>>> header for prefetch: Fetch Standard >>>> <https://fetch.spec.whatwg.org/#:~:text=If%20httpRequest%E2%80%99s%20initiator%20is%20%22prefetch%22%2C%20then%20set%20a%20structured%20field%20value%20given%20(%60Sec%2DPurpose%60%2C%20the%20token%20prefetch)%20in%20httpRequest%E2%80%99s%20header%20list> >>>> >>>> >>>> Positive for Mozilla as they've already mainly migrated to using the >>>> header, >>>> and not planned for Webkit and they don't support rel=prefetch. >>>> >>>> On Monday, May 12, 2025 at 7:45:16 AM UTC-7 Steven Wei wrote: >>>> >>>>> Thanks! Added an issue to whatwg/html repo: Can we include what >>>>> header(s) get sent with link type prefetch? · Issue #11294 · whatwg/html >>>>> <https://github.com/whatwg/html/issues/11294> >>>>> Also, I don't think Safari supports <link rel=prefetch>. >>>>> >>>>> Also, started vendor position requests: >>>>> Mozilla: Send Sec-Purpose header for link type prefetch >>>>> (rel=prefetch) · Issue #1228 · mozilla/standards-positions >>>>> <https://github.com/mozilla/standards-positions/issues/1228> >>>>> Webkit: Send Sec-Purpose header for link type prefetch >>>>> (rel=prefetch) · Issue #493 · WebKit/standards-positions >>>>> <https://github.com/WebKit/standards-positions/issues/493> >>>>> >>>>> On Thursday, May 8, 2025 at 2:30:17 PM UTC-7 yoav...@chromium.org >>>>> wrote: >>>>> >>>>> On Thu, May 8, 2025 at 11:11 PM Chromestatus < >>>>> ad...@cr-status.appspotmail.com> wrote: >>>>> >>>>> Contact emails stev...@microsoft.com >>>>> >>>>> Explainer https://github.com/w3c/resource-hints/issues/74 >>>>> >>>>> Specification >>>>> https://chromium-review.googlesource.com/c/chromium/src/+/6334746 >>>>> >>>>> >>>>> That's not a specification. Is it possible to file an issue on HTML >>>>> and try to bake that into the standard? >>>>> >>>>> >>>>> >>>>> Summary >>>>> >>>>> Chrome currently passes both 'Purpose: prefetch' and 'Sec-Purpose: >>>>> prefetch' headers as part of prefetch through speculation rules. However, >>>>> only 'Purpose: prefetch' is passed with <link rel=prefetch>. We plan to >>>>> standardize this header for both speculation rules and <link >>>>> rel=prefetch> >>>>> by adding 'Sec-Purpose: prefetch' header to the latter. Future work will >>>>> involve stop sending 'Purpose: prefetch' for prefetches, prerenders, etc. >>>>> >>>>> >>>>> 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 Pending >>>>> >>>>> 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*: No signal Firefox has sent ‘X-moz: prefetch’. >>>>> >>>>> *WebKit*: No signal Safari has sent 'Purpose: prefetch' but changed >>>>> to use 'X-Purpose: preview'. >>>>> >>>>> >>>>> Can you open vendor position requests and try to get them on board >>>>> this change? >>>>> >>>>> Also, does Safari support <link rel=prefeftch>? Or is that for URL bar >>>>> driven prefetches? >>>>> >>>>> >>>>> >>>>> *Web developers*: No signals >>>>> >>>>> >>>>> With my web developer hat on, these different headers are definitely a >>>>> hurdle and can cause some prefetches to be missed. >>>>> >>>>> >>>>> >>>>> >>>>> *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 >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? No >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? No >>>>> >>>>> Plan to add a new test. >>>>> >>>>> >>>>> Flag name on about://flags None >>>>> >>>>> Finch feature name None >>>>> >>>>> Non-finch justification None >>>>> >>>>> Rollout plan Will ship enabled for all users >>>>> >>>>> Requires code in //chrome? False >>>>> >>>>> Tracking bug https://issues.chromium.org/issues/40236973 >>>>> >>>>> Estimated milestones >>>>> >>>>> No milestones specified >>>>> >>>>> >>>>> 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/6247959677108224?gate=4656924191096832 >>>>> >>>>> Links to previous Intent discussions Intent to Prototype: >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/680fb6c9.050a0220.1699c.03f6.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+...@chromium.org. >>>>> To view this discussion visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/681d1e1b.050a0220.d6048.0024.GAE%40google.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/681d1e1b.050a0220.d6048.0024.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+...@chromium.org. >>>> >>>> To view this discussion visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/70f2338a-168f-4747-be74-2784fb90f436n%40chromium.org >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/70f2338a-168f-4747-be74-2784fb90f436n%40chromium.org?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/1a0eefbc-6eb1-4223-99e5-4d85f664fcddn%40chromium.org.
