fix(fetch): keep the cookie header passed by the caller on redirects

[abhijeet sharma (thegoodengineer)]

Fixes #42840

APIRequestContext honors an explicit cookie header on the first request (headers and extraHTTPHeaders win over the context cookie store), but dropped it unconditionally before following a redirect. Context cookies were merged into the same headers object, so the redirect code could not tell the caller's header apart from the ones added from the store and removed both. The redirected request went out with only whatever the store had for the new URL, which is nothing for a standalone request context. The documentation for the headers option promises that headers "will apply to the fetched request as well as any redirects initiated by it".

Changes

• Context cookies are added to a per-request copy of the headers. options.headers now only ever holds what the caller passed, so redirects carry an explicit cookie header over like every other header.
• On a cross-origin redirect the cookie header is dropped together with authorization, and the cookie store is consulted for the new origin, following fix(fetch): drop authorization and recompute client cert on cross-ori… #40547.
• Cookies set by a redirect response are applied to the explicit cookie header for the next hop (added when they match the next URL, replaced when the name is already present, removed when expired), the same way they are stored in the context. This keeps route.fetch() correct: it forwards the cookie header captured from the browser, and the session cookie set by a login redirect has to reach the redirect target.
• The cookie header parsing used for the request event is shared with the new helper.

Requests without an explicit cookie header are unaffected: the store is still consulted for every hop.

Tests

• browsercontext-fetch.spec.ts: an explicit header is kept across two same-origin redirects while the store has a cookie for the host; cookies set by redirect responses are added, skipped on path mismatch, updated and expired on the following hops; an explicit header is dropped on a cross-origin redirect and the store cookie for that origin is used instead.
• global-fetch.spec.ts: a cookie from extraHTTPHeaders is kept on a same-origin redirect and dropped on a cross-origin one, mirroring the existing authorization test.
• page-request-intercept.spec.ts: route.fetch() through a redirect that sets a session cookie sends both the browser cookie and the new one to the redirect target.

The three tests for explicit headers on same-origin redirects fail on main and pass with this change. The cross-origin test and the route.fetch() test pass on both and pin down the behavior that must not change.

Verified locally in Chromium, Firefox and WebKit with browsercontext-fetch, global-fetch, page-request-intercept and page-route; npm run tsc and eslint pass.

[abhijeet sharma (thegoodengineer)]

@microsoft-github-policy-service agree