Intent to Ship: Propagate request origin and redirect chain in passthrough service workers.

168 views
Skip to first unread message

Ben Kelly

unread,
Nov 24, 2021, 4:40:54 PM11/24/21
to blink-dev

Contact emails

wande...@chromium.org

Explainer

None

Specification

https://github.com/whatwg/fetch/pull/1345

Summary

This feature will cause service workers that handle navigation requests by calling `fetch(evt.request)` to use the origin and redirect chain from `FetchEvent.request`. Previously this information was always set to the service worker's origin with no redirect chain. This information is used to control the origin header and SameSite cookies sent with the request to the server.



Blink component

Blink>ServiceWorker

TAG review

We did not perform a TAG review as this is a small change to existing specs and we had consensus in the Service Worker Working Group.

TAG review status

Not applicable

Risks



Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:


Debuggability

N/A



Is this feature fully tested by web-platform-tests?

Yes

Flag name



Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1241188

Estimated milestones

No milestones specified



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5752539724120064

This intent message was generated by Chrome Platform Status.

Ben Kelly

unread,
Nov 24, 2021, 4:52:06 PM11/24/21
to blink-dev
On Wed, Nov 24, 2021 at 4:40 PM Ben Kelly <wande...@chromium.org> wrote:

Interoperability and Compatibility



Gecko: No signal

I have not filed for formal signals, but we had a TPAC session with mozilla where we reached consensus on these changes.
 
WebKit: No signal

Note, webkit already propagates the origin header.  They do not implement sec-fetch-site or SameSite cookies, so the redirect chain propagation is not observable or relevant.

Chris Harrelson

unread,
Nov 24, 2021, 5:03:56 PM11/24/21
to Ben Kelly, blink-dev
LGTM1

--
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/CAK7rkMjWDoVDeuNnYVuOOS4OjEKrRUkKSt9G9CwT13T_PPS6nQ%40mail.gmail.com.

Rick Byers

unread,
Nov 24, 2021, 5:07:15 PM11/24/21
to Chris Harrelson, Ben Kelly, blink-dev
Ben, can you speak to the web compat implications (or absence thereof) to this change in behavior?

Ben Kelly

unread,
Nov 24, 2021, 5:27:30 PM11/24/21
to Rick Byers, Chris Harrelson, blink-dev


On Wed, Nov 24, 2021, 5:07 PM Rick Byers <rby...@chromium.org> wrote:
Ben, can you speak to the web compat implications (or absence thereof) to this change in behavior?

I believe the compat risk should be minimal.  This change only matters for navigation requests and many service workers will be using nav preload instead of calling fetch() themselves.

For sites not using nav preload it's possible they will see changes in origin headers, sec-fetch-site headers, and SameSite=Strict cookies.  Depending on server logic that could cause requests to be deemed unsafe by the server and fail.  However, it would match what is done without a service worker present.  Arguably the server wants to make this decision in these situations.

If a site does not want this behavior it requires only a small service worker change to get previous behavior.  They just need to fetch the url and not the full request.  Like `fetch(evt.request.url)` instead of `fetch(evt.request)`.

Rick Byers

unread,
Nov 24, 2021, 5:59:14 PM11/24/21
to Ben Kelly, Chris Harrelson, blink-dev
Makes sense, thanks! Arguably almost a bugfix level change. LGTM2

Mike West

unread,
Nov 25, 2021, 1:21:53 AM11/25/21
to Rick Byers, Ben Kelly, Chris Harrelson, blink-dev

Ben Kelly

unread,
Nov 29, 2021, 10:11:28 AM11/29/21
to Mike West, Rick Byers, Chris Harrelson, blink-dev
Thank you!

FYI, I realized this morning I made one small mistake in my original post.  The origin propagation part of this intent is actually in M97 and the redirect chain part is in M98.  The CLs are large, so I don't really want to do a merge if I can avoid it.  Since the first part of the change is in M97 I updated the chromestatus entry to indicate that as the release and added a note that the redirect-chain change is coming in M98.  Sorry for the confusion here.

Please let me know if there is any concern about this clarification.  Thanks.

Joe Medley

unread,
Nov 30, 2021, 3:24:10 PM11/30/21
to Ben Kelly, Mike West, Rick Byers, Chris Harrelson, blink-dev
>Since the first part of the change is in M97 I updated the chromestatus entry to indicate that as the release and added a note that the redirect-chain change is coming in M98.

Is any of this feature usable in 97? 
Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195
If an API's not documented it doesn't exist.


Ben Kelly

unread,
Nov 30, 2021, 3:27:47 PM11/30/21
to Joe Medley, Mike West, Rick Byers, Chris Harrelson, blink-dev
On Tue, Nov 30, 2021 at 3:24 PM Joe Medley <jme...@google.com> wrote:
>Since the first part of the change is in M97 I updated the chromestatus entry to indicate that as the release and added a note that the redirect-chain change is coming in M98.

Is any of this feature usable in 97? 

Yes.  Requests without a redirect will work in M97 and get the expected origin header, sec-fetch-site header, and samesite cookies.  Some restrictions redirected requests will only start being applied in M98.

Rafael Santos Silva

unread,
Jan 12, 2022, 5:50:47 PM (11 days ago) Jan 12
to blink-dev, wande...@chromium.org, mk...@chromium.org, rby...@chromium.org, Chris Harrelson, blink-dev, Joe Medley

This change broke a SingleSignOn login on the FOSS software Discourse. We have a flow like:

1. User visits forum.siteA.com, click login
2. Gets redirected to idp.siteB.com
3. Fills login details
5. Gets redirected to forum.siteA.com/homepage

On step 4, the response includes a `set-cookie` header, with proper `HttpOnly; SameSite=Lax; Secure `and set. But if there is an active service worker, the login will fail as that cookie will be rejected by Chromium due to SameSite rules now.

t=2971 [st=258]        COOKIE_INCLUSION_STATUS
                       --> domain = "forum.siteA.com"
                       --> name = "_t"
                       --> operation = "store"
                       --> path = "/"
                       --> status = "EXCLUDE_SAMESITE_LAX, DO_NOT_WARN"

The service worker is a vanilla WorkboxJS service worker that intercepts all GETs with the "Network First" strategy.

Disabling the service worker or using Firefox results in a successful login. There is no warning in either DevTools network tab nor the console that the cookie was rejected.

Chrome 96: login works
Chrome 97: login does not work
Chrome 98: login does not work

Is this expected behavior? Even if the request `GET forum.siteA.com` was initiated because of a redirect from a different domain, is it expected that Chrome will silently drop same site cookies from forum.siteA.com?

Did not post this in the https://bugs.chromium.org/p/chromium/issues/detail?id=1241188 because it's not public.

Ben Kelly

unread,
Jan 13, 2022, 10:15:34 AM (10 days ago) Jan 13
to Rafael Santos Silva, blink-dev, mk...@chromium.org, rby...@chromium.org, Chris Harrelson, Joe Medley
Please re-test with canary 99.0.4827.0 or later.

For more information see:

Reply all
Reply to author
Forward
0 new messages