← Back to microsoft/playwright
microsoft / playwright · Issue No. 41932
1.61.1
Clone my repo at https://github.com/achingbrain/safari-service-worker-playwright-fetch-headers
npm i
npm run test
When a service worker is installed it intercepts all browser requests, either from the address bar or from window.fetch running on a page.
When Playwright routes are enabled, it disables HTTP caching. In Safari it seems to do this by sending a cache-control: no-cache header.
If a browser request is made via window.fetch, custom headers can be specified, including cache-control.
In Chromium, specifying a cache-control header on a window.fetch request intended to be intercepted by a service worker works as expected, the service worker sees the correct cache-control value.
In WebKit it doesn't, the service worker always sees cache-control: no-cache, regardless of what the user specified.
I would expect WebKit to match the Chromium behaviour and allow specifying cache-control values.
Service workers running in WebKit always receive cache-control: no-cache, regardless of what the user specified.
The test in my application this affects ensures that the cache-control header is handled correctly by the service worker. It's impossible for this to pass if the test cannot control the cache-control header value.
It also has a catch-all route configured to ensure the test doesn't accidentally make requests to the actual internet which creates the conflict described above.
Additionally, WebKit always receives accept-language: en-US and the value cannot be overridden, it Chromium it can. This also seems like a bug.
The accept header seems to work as expected in Chromium and WebKit.
System:
OS: macOS 26.5.1
CPU: (16) arm64 Apple M4 Max
Memory: 4.51 GB / 64.00 GB
Binaries:
Node: 24.13.1 - /Users/alex/.nvm/versions/node/v24.13.1/bin/node
npm: 11.8.0 - /Users/alex/.nvm/versions/node/v24.13.1/bin/npm
pnpm: 11.4.0 - /Users/alex/.nvm/versions/node/v24.13.1/bin/pnpm
Deno: 2.7.12 - /Users/alex/.nvm/versions/node/v24.13.1/bin/deno
IDEs:
VSCode: 1.128.0 - /usr/local/bin/code
Languages:
Bash: 3.2.57 - /bin/bash
npmPackages:
@playwright/test: ^1.61.1 => 1.61.1
Relay reads this issue against the repository's contribution signals: the files it is likely to touch, how the maintainers triage work this size, and what the first contribution would exercise.
The full analysis for this issue is still being assembled. Until then, the description above and the thread on GitHub are the most reliable context.