microsoft / microsoft/playwright

[Bug]: When routes are enabled, Service Worker fetch requests always receive a `cache-control` header in WebKit

Open
#41,932 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

browser-webkit upstream
Dominant language
TypeScript
Stars
96.3k
Forks
6.5k
Avg merge
1d 6h
Merged PRs (30d)
180

Description

### Version

1.61.1

### Steps to reproduce

Clone my repo at https://github.com/achingbrain/safari-service-worker-playwright-fetch-headers

```console
npm i
npm run test
```

### Expected behavior

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.

### Actual behavior

Service workers running in WebKit always receive `cache-control: no-cache`, regardless of what the user specified.

### Additional context

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.

### Environment

```shell
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
```

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Clone the linked safari-service-worker-playwright-fetch-headers repository and run `npm i` followed by `npm run test` to reproduce the WebKit behavior. Trace Playwright route handling and WebKit service-worker request headers, then add coverage showing that caller-provided `cache-control` and `accept-language` values are preserved as expected.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript
Domain
testing-qa, web-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.