Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Service-Worker fetch registration #550

Open
csharrison opened this issue Sep 2, 2022 · 2 comments
Open

Support Service-Worker fetch registration #550

csharrison opened this issue Sep 2, 2022 · 2 comments

Comments

@csharrison
Copy link
Collaborator

csharrison commented Sep 2, 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.

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.

@csharrison
Copy link
Collaborator Author

csharrison commented Sep 16, 2022

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:

  1. Support fetches from within SW
  2. 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.

@csharrison
Copy link
Collaborator Author

csharrison commented Sep 19, 2022

Given the Chromium bug, renaming this issue to more accurately needs to be done w/in the proposal.

@csharrison csharrison changed the title Misconfigured service workers can cause unexpected behavior on redirect Support Service-Worker fetch registration Sep 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant