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

Vary and requests added after the SW #1542

Closed
yoavweiss opened this issue Sep 24, 2020 · 6 comments
Closed

Vary and requests added after the SW #1542

yoavweiss opened this issue Sep 24, 2020 · 6 comments

Comments

@yoavweiss
Copy link

yoavweiss commented Sep 24, 2020

I learned recently that Cache.match() is taking the Vary headers into account when matching requests and responses. That seems neat.

At the same time, for request headers added after the SW (e.g. Cookie, User-Agent) that doesn't seem like something that can work: The server indicates that the request would vary based on the user state or browser version, but that is not respected because the Request objects the SW's fetch event sees don't contain those headers and would always match, even if those headers changed in the underlying layers.

The reason I'm looking into this is that for Client Hints, we decided on adding them above the SW in order to have visibility into their values when matching responses, but that has many downsides, especially when it comes to SW generated requests.

Maybe the right path here is a way to provide those relevant values to match() (coming from the relevant JS APIs) in a generic way that'd enable it to take them into account?

@wanderview
Copy link
Member

wanderview commented Sep 24, 2020

I'm not sure I understand the issue. The VARY header is indeed on the request, but that just instructs the matching algorithm as to which headers to inspect on the response. So I'm not sure it matters to cache.match() when the browser sets certain request headers since this algorithm is comparing response headers.

@yoavweiss
Copy link
Author

It's the other way around.
Vary is a response header, which value indicates which request headers should be considered when matching requests to responses.
That way, a response with Vary: User-Agent that was cached in response to a request with a User-Agent header of Chrome 86 will no longer match requests with the Chrome 87 UA string.

@wanderview
Copy link
Member

Oh, yes. Sorry for my confusion.

@mfalken
Copy link
Member

mfalken commented Oct 21, 2020

Sorry, what does "below" mean here?

Last I understood, Chrome sets the User Agent header before the service worker (i.e., the SW sees the UA header).

The spec says the User Agent header should be set after the service worker (i.e., the SW doesn't see the UA header).

Related bugs are https://crbug.com/595993, https://crbug.com/962620, https://crbug.com/963260

@yoavweiss
Copy link
Author

Apologies for the confusing langauge. By "below", I meant "added after SWs".

@yoavweiss yoavweiss changed the title Vary and requests added below the SW Vary and requests added after the SW Oct 21, 2020
@yoavweiss
Copy link
Author

We discussed this in last week's call.
I think we can close this, as it seems like a better design to add headers before the SWs, rather than somehow expose the same variables to Vary. For Client Hints specifically, I outlined the solution I have in mind.

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

3 participants