Re: Intent to Ship: Fetch Metadata Destination header

98 views
Skip to first unread message

Mike West

unread,
Nov 26, 2019, 8:26:42 AM11/26/19
to Yifan Luo, blink-dev
My name is on this, so I'm abstaining. But if I wasn't abstaining, I'd LGTM0 it. :)

On Tue, Nov 26, 2019 at 2:22 PM Yifan Luo <l...@google.com> wrote:


-mike 


There are also outstanding PRs against Fetch, HTML, and etc. that we should point to to explain some of the underlying mechanics

https://github.com/whatwg/fetch/pull/948 (contains way more discussion than a PR really should :) )

-mike

https://github.com/w3ctag/design-reviews/issues/280 Introduces a new HTTP request header `Sec-Fetch-Dest` which is part of the fetch metadata request headers that sends additional metadata about a request's destination to provide servers with more information to make security decisions. https://groups.google.com/a/chromium.org/d/msg/blink-dev/tNwA_l_o9lc/5wug6BcmCQAJ
The biggest risk for deployment is that different browsers send different header values for the same kind of request. We're attempting to mitigate this risk with a reasonably robust test suite, and with recommendations in the spec for browser-specific features that are difficult to test via WPT. Firefox: Mixed public signals (https://github.com/whatwg/fetch/pull/948#issuecomment-543080576) Edge: No public signals Safari: No public signals Web developers: No signals The feature exposes additional metadata about a given request, enabling servers to make informed decisions about the ways in which they respond.
These headers are discoverable in devtools, just like any other header. Yes Yes https://wpt.fyi/results/fetch/metadata?label=experimental&label=master&aligned https://bugs.chromium.org/p/chromium/issues/detail?id=843478 https://chromestatus.com/feature/5206259592593408
This intent message was generated by Chrome Platform Status.

Yifan Luo

unread,
Nov 26, 2019, 3:17:18 PM11/26/19
to blink-dev, Mike West
l...@chromium.org https://github.com/mikewest/sec-metadata https://w3c.github.io/webappsec-fetch-metadata/ https://github.com/w3ctag/design-reviews/issues/280 Introduces a new HTTP request header `Sec-Fetch-Dest` which is part of the fetch metadata request headers that sends additional metadata about a request's destination to provide servers with more information to make security decisions. https://groups.google.com/a/chromium.org/d/msg/blink-dev/tNwA_l_o9lc/5wug6BcmCQAJ

Yoav Weiss

unread,
Dec 2, 2019, 5:11:12 AM12/2/19
to Mike West, Yifan Luo, blink-dev
LGTM1

On Tue, Nov 26, 2019 at 2:26 PM Mike West <mk...@chromium.org> wrote:
My name is on this, so I'm abstaining. But if I wasn't abstaining, I'd LGTM0 it. :)

On Tue, Nov 26, 2019 at 2:22 PM Yifan Luo <l...@google.com> wrote:


Would be good to spell out how destination should and shouldn't be used: there are a bunch of subtleties around `destination`, Service-Workers and subresources that developers should be careful about.
 

-mike 


There are also outstanding PRs against Fetch, HTML, and etc. that we should point to to explain some of the underlying mechanics

https://github.com/whatwg/fetch/pull/948 (contains way more discussion than a PR really should :) )

-mike

https://github.com/w3ctag/design-reviews/issues/280 Introduces a new HTTP request header `Sec-Fetch-Dest` which is part of the fetch metadata request headers that sends additional metadata about a request's destination to provide servers with more information to make security decisions. https://groups.google.com/a/chromium.org/d/msg/blink-dev/tNwA_l_o9lc/5wug6BcmCQAJ
The biggest risk for deployment is that different browsers send different header values for the same kind of request. We're attempting to mitigate this risk with a reasonably robust test suite, and with recommendations in the spec for browser-specific features that are difficult to test via WPT. Firefox: Mixed public signals (https://github.com/whatwg/fetch/pull/948#issuecomment-543080576) Edge: No public signals Safari: No public signals

Have we reached out to Safari? Opened a WebKit bug?
 
Web developers: No signals The feature exposes additional metadata about a given request, enabling servers to make informed decisions about the ways in which they respond.
These headers are discoverable in devtools, just like any other header. Yes Yes https://wpt.fyi/results/fetch/metadata?label=experimental&label=master&aligned https://bugs.chromium.org/p/chromium/issues/detail?id=843478 https://chromestatus.com/feature/5206259592593408
This intent message was generated by Chrome Platform Status.

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdQTqT5C_JBL5Yk51xLb0rNp4%3DmD38xH4ag1NWLhhiDDQ%40mail.gmail.com.

Mike West

unread,
Dec 2, 2019, 7:56:33 AM12/2/19
to Yoav Weiss, Yifan Luo, blink-dev
On Mon, Dec 2, 2019 at 11:11 AM Yoav Weiss <yo...@yoav.ws> wrote:
LGTM1

On Tue, Nov 26, 2019 at 2:26 PM Mike West <mk...@chromium.org> wrote:
My name is on this, so I'm abstaining. But if I wasn't abstaining, I'd LGTM0 it. :)

On Tue, Nov 26, 2019 at 2:22 PM Yifan Luo <l...@google.com> wrote:


Would be good to spell out how destination should and shouldn't be used: there are a bunch of subtleties around `destination`, Service-Workers and subresources that developers should be careful about.

I agree, especially around `<embed>` and `<object>`. We have some ideas about non-normative "Implementation Considerations" that we can add, which will likely build upon Google security's experience that they've started documenting on https://secmetadata.appspot.com/. 
 
 

-mike 


There are also outstanding PRs against Fetch, HTML, and etc. that we should point to to explain some of the underlying mechanics

https://github.com/whatwg/fetch/pull/948 (contains way more discussion than a PR really should :) )

-mike

https://github.com/w3ctag/design-reviews/issues/280 Introduces a new HTTP request header `Sec-Fetch-Dest` which is part of the fetch metadata request headers that sends additional metadata about a request's destination to provide servers with more information to make security decisions. https://groups.google.com/a/chromium.org/d/msg/blink-dev/tNwA_l_o9lc/5wug6BcmCQAJ
The biggest risk for deployment is that different browsers send different header values for the same kind of request. We're attempting to mitigate this risk with a reasonably robust test suite, and with recommendations in the spec for browser-specific features that are difficult to test via WPT. Firefox: Mixed public signals (https://github.com/whatwg/fetch/pull/948#issuecomment-543080576) Edge: No public signals Safari: No public signals

Have we reached out to Safari? Opened a WebKit bug?

We've poked WebKittens about Fetch Metadata generally and CC'd some folks on GitHub issues, without much engagement. I hadn't filed a "Please implement this" bug, but I'll do so now: https://bugs.webkit.org/show_bug.cgi?id=204744.

-mike

Rick Byers

unread,
Dec 2, 2019, 11:12:55 AM12/2/19
to Yifan Luo, blink-dev, Mike West
LGTM2

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/364bb763-26b3-47ec-8bd1-3579c6e281ae%40chromium.org.

Jochen Eisinger

unread,
Dec 3, 2019, 4:16:54 AM12/3/19
to Rick Byers, Yifan Luo, blink-dev, Mike West
lgtm3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9N9PeNQJ-SxqAWpeQDk5EFFEYUnzESCBU5%3Dd5E-6EAiQ%40mail.gmail.com.

Ben Kelly

unread,
May 20, 2020, 11:58:25 AM5/20/20
to Jochen Eisinger, Rick Byers, Yifan Luo, blink-dev, Mike West
Just FYI, I'm seeing reports from developers that are confused by the Request.destination changes here.  Specifically, they were doing `request.destination == 'document'` in their service worker to determine if a navigation preload should be processed.  These checks are failing for framed loads now because the destination is instead 'iframe'.  All their iframe loads are now slower and they are seeing many rejected promise errors from the preloadResponse promise being left unhandled.

In addition to a breaking change this is a bit more confusing for developers since the spec PR to fetch has not merged.  The developer I spoke too wrote their service worker based on looking at the spec.

I'm not trying to call out anyone here.  I understand sometimes we need to ship things before the spec can be formally updated and in this case we are working to get the PR merged soon.  But this case does seem a suboptimal outcome and I just wanted to flag it in case there is any improvement to the process that could be made for the future.

Also, should we do some kind of web developer outreach about this change?

Thanks.

Ben

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjhuieak2bjN_bp0XHLnpbgUf09RB2BYjhrh_3NPe_U3uM-%3DQ%40mail.gmail.com.

Yoav Weiss

unread,
May 20, 2020, 3:55:42 PM5/20/20
to Ben Kelly, Jochen Eisinger, Rick Byers, Yifan Luo, blink-dev, Mike West
:(

Apologies. I missed the fact that this change also modified the web exposed Request.destination when reviewing.


On Wed, May 20, 2020 at 5:58 PM Ben Kelly <wande...@chromium.org> wrote:
Just FYI, I'm seeing reports from developers that are confused by the Request.destination changes here.  Specifically, they were doing `request.destination == 'document'` in their service worker to determine if a navigation preload should be processed.  These checks are failing for framed loads now because the destination is instead 'iframe'.  All their iframe loads are now slower and they are seeing many rejected promise errors from the preloadResponse promise being left unhandled.

In addition to a breaking change this is a bit more confusing for developers since the spec PR to fetch has not merged.  The developer I spoke too wrote their service worker based on looking at the spec.

I'm not trying to call out anyone here.  I understand sometimes we need to ship things before the spec can be formally updated and in this case we are working to get the PR merged soon.  But this case does seem a suboptimal outcome and I just wanted to flag it in case there is any improvement to the process that could be made for the future.

Also, should we do some kind of web developer outreach about this change?

I think it would be good to assess how much existing SW code is looking into Request.destination under the assumption its value is "document" for iframes. 


Reply all
Reply to author
Forward
0 new messages