You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here is a common flow for "default" handling of requests going through service workers that doesn't work with the API. The case is a conversion ping which redirects through two domains.
sequenceDiagram
participant P as Page
participant S as Service worker
participant A1 as Ad server 1
participant A2 as Ad server 2
P->>S: 1. Request for ad1.com/conversion-ping
S->>A1: 2. Request for ad1.com/conversion-ping
A1->>S: 3. Redirect
S->>A2: 4. Request for ad2.com/conversion-ping
A2->>S: 5. Respond with Attribution Reporting headers
S->>P: 6. Respond to (1) with response from (5)
Currently, the API does not support fetches from within service workers (at least, in the Chromium implementation - the spec is not defined right now on this matter), so there is only a single registration at (6), not one also at (5).
The problem is that the API registration should be associated with ad2.com, but it incorrectly gets associated with ad1.com because the Service Worker is just copying the response wholesale. Worse still, if ad1.com also wanted to register with API headers at (3), they would see very strange behavior indeed because their headers would get replaced with the headers from ad2.com.
The workaround is to avoid the Service Worker URL interception entirely by not calling respondWith for the associated registration fetch events.
Concretely, we should: 1. Highlight as a note in the spec the behavior on (6), and reference the workaround.
2. Consider this case when deciding whether the API should formally support requests from within a Service Worker. Note that supporting this could have bad outcomes in that we may introduce duplicate registrations in the above diagram, especially for non-redirected requests. Let's proceed with caution here.
The text was updated successfully, but these errors were encountered:
I chatted with @wanderview about this at TPAC and I think there is a bug in the Chromium implementation. I filed crbug.com/1364447 with more details.
I think the real fix to this is to:
Support fetches from within SW
Stop supporting fetches served by SW (e.g. look at WasFetchedViaServiceWorker)
Note that (2) does stop the duplication issue, but it might break some legit use-cases where SW are actually needed to use the API, it would be good to get feedback if this is the case.
Given the Chromium bug, renaming this issue to more accurately needs to be done w/in the proposal.
csharrison
changed the title
Misconfigured service workers can cause unexpected behavior on redirect
Support Service-Worker fetch registration
Sep 19, 2022
Here is a common flow for "default" handling of requests going through service workers that doesn't work with the API. The case is a conversion ping which redirects through two domains.
Currently, the API does not support fetches from within service workers (at least, in the Chromium implementation - the spec is not defined right now on this matter), so there is only a single registration at (6), not one also at (5).
The problem is that the API registration should be associated with
ad2.com
, but it incorrectly gets associated withad1.com
because the Service Worker is just copying the response wholesale. Worse still, if ad1.com also wanted to register with API headers at (3), they would see very strange behavior indeed because their headers would get replaced with the headers from ad2.com.The workaround is to avoid the Service Worker URL interception entirely by not calling
respondWith
for the associated registrationfetch
events.Concretely, we should:
1. Highlight as a note in the spec the behavior on (6), and reference the workaround.2. Consider this case when deciding whether the API should formally support requests from within a Service Worker. Note that supporting this could have bad outcomes in that we may introduce duplicate registrations in the above diagram, especially for non-redirected requests. Let's proceed with caution here.
The text was updated successfully, but these errors were encountered: