`SELF.fetch()` doesn't carry cookies across redirects

[jimmycallin]

What versions & operating system are you using?

System:
OS: macOS 15.5
CPU: (8) arm64 Apple M2
Memory: 178.98 MB / 24.00 GB
Shell: 4.0.2 - /opt/homebrew/bin/fish
Binaries:
Node: 22.17.1 - ~/.local/state/fnm_multishells/13811_1754254652214/bin/node
npm: 10.9.2 - ~/.local/state/fnm_multishells/13811_1754254652214/bin/npm
bun: 1.2.19 - ~/.bun/bin/bun
npmPackages:
@cloudflare/vitest-pool-workers: ^0.8.59 => 0.8.59

Please provide a link to a minimal reproduction

https://github.com/jimmycallin/cloudflare-workers-vitest-redirect-issue

Describe the Bug

When testing Cloudflare Workers with Vitest, SELF.fetch automatically follows redirects but fails to carry cookies from the initial response to the redirected request. This breaks testing scenarios that depend on cookie-based session management across redirects.

The only workaround I've found is to use worker.fetch directly which does not follow redirects, and manually make the second redirect while carrying over the cookie header, but I haven't been able to to integrate this with D1 and use vi.mock() to mock modules at the same time. Please correct me if I'm wrong.

Please provide any relevant error logs

No response

[petebacondarwin]

Thanks for this issue report.
Would it be enough to add support for turning off automatic redirect following?
Or do we need to implement both aspects?

[petebacondarwin]

One concern with passing on the cookies is that it would be a potential security risk so we would need to ensure that they are only passed on if the domains are compatible between the original request and the redirected request.

[jimmycallin]

I would be happy with an option to turn off automatic redirect following, but if you want to keep around the automatic redirect following, I would argue that not passing on cookies would be a common source of confusion. Optimally it would be implemented, but the very least it should be prominently documented it's not supported with recommended workarounds.

[petebacondarwin]

Just playing around with this. The integration style of fetching from a Worker is that env.SELF is setup like a service binding.
But interestingly, if I create a separate Worker and binding to your Worker above. E.g.

export default {
  async fetch(r, e) {
    const response = await e.TEST.fetch(r);
    console.log(
      "Response from TEST service:",
      response.status,
      response.headers.get("set-cookie")
    );
    return new Response("OK");
  },
};

Then it doesn't follow the redirect:

Response from TEST service: 302 user_id=user-id; Max-Age=604800; Path=/; HttpOnly; Secure; SameSite=Lax

[petebacondarwin]

The problem we have in making SELF.fetch pretend it is making a fetch as though it was a browser is that the Worker doesn't really have the same kind of state as a browser. In a browser what happens is that the redirect response comes back with the cookie header on it; the browser then stores that cookie in its cookie store; then every request after that will contain that cookie in its request (not just the redirected URL request).

We would need to change env.SELF to be some kind of wrapper around the service binding that has some kind of local context that stores the cookies from previous responses.

This seems prone to issues, and I would rather avoid that. So I would propose that we just make following redirects disabled (or configurable).

[jimmycallin]

You may find mswjs's implementation of this interesting: mswjs/interceptors#627

[petebacondarwin]

OK so the first thing to know, in case you hadn't realised, is that you can already configure the fetch not to follow the redirects automatically. Just change the line in your test to:

    const response = await SELF.fetch("https://api.example.com/user", {
      redirect: "manual",
    });

I think this should unblock you, right?

[petebacondarwin]

So to be concrete, this test will pass:

const response = await SELF.fetch("https://api.example.com/user", {
  redirect: "manual",
});
expect(response.status).toBe(302);
const data = await response.text();
expect(data).toMatchInlineSnapshot(`""`);
expect(response.headers.get("set-cookie")).toContain("user_id=user-id");

[jimmycallin]

this seems to work - thank you!

not sure if this is a known issue or a me issue, but SELF.fetch is of type any for me making discoverability a bit difficult.

[petebacondarwin]

You are seeing any because the test/tsconfig.json that is used to define the typings for the test directory doesn't reference the worker-configuration.d.ts file. Change the include there to:

  "include": ["./**/*.ts", "./**/*.tsx", "../worker-configuration.d.ts"],