Re: [w3c/ServiceWorker] Support No-Vary-Search header in Cache API (Issue #1798)

yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1798)

Thanks for pointing out the security risk with opaque resources.

I agree that a fully explicit approach is the right way to avoid information leaks. To build on that idea, as you suggested, we should require the developer to provide the actual `No-Vary-Search` rules to both `put()` and `match()`, rather than just a boolean `noVarySearch: true` flag.

For example:
```
const rules = 'params, except=("id")';
await cache.put(request, response, { noVarySearchRules: rules });
const match = await cache.match(requestWithOtherParams, { noVarySearchRules: rules });
```
Note that the logic ignores `No-Vary-Search` header in the response.  This approach directly addresses the security concern you raised. The matching logic would rely entirely on the rules provided by the developer at runtime.

This also seems like a natural fit for the Cache API's design. The Service Worker specification defines the Cache API as a straightforward key-value store, unlike the browser's HTTP cache, which can employ implicit, path-based mechanisms to remember the last seen header. Since the Cache API doesn't have a mechanism for storing metadata per directory, requiring the rule at `match()` time is necessary to resolve ambiguity and aligns with the explicit nature of the API.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1798#issuecomment-3460651303
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1798/3460651303@github.com>