Closed sean-roberts closed 10 months ago
It should be transparent to the service workers (as is gzip and brotli encoding). If the request makes it to the network then the appropriate content encoding will be negotiated but the worker will see the decoded response.
And FWIW, the browser caching layers aren't skipped with service workers, the cache is downstream of the workers so if a fetch goes through a worker it will still go through cache before going out to the network.
And FWIW, the browser caching layers aren't skipped with service workers, the cache is downstream of the workers so if a fetch goes through a worker it will still go through cache before going out to the network.
Ah sorry, I was confusing an issue that was related to a browser problem we were having with navigation preload requests not sending if-none-match, not general caching.
It should be transparent to the service workers (as is gzip and brotli encoding). If the request makes it to the network then the appropriate content encoding will be negotiated but the worker will see the decoded response.
Ok, excellent!
Apologies if there are some specifics that I missed around this but I'm curious how service workers will interact with this solution. It's clearly at a lower layer and no API for SW but is it expected that, when using SW to make fetch requests, this process still happens or should it be skipped? Atm, typical browser caching layers are skipped with SW networking - for example, responses sending a etag header will not go through the process for which the request will have a if-none-match header, the SW needs to incorporate that.