docs(network): explain how request interception relates to the network stack - #42646
Conversation
…k stack References: microsoft#42620
Test results for "tests 1"5 flaky51528 passed, 1246 skipped Merge workflow run. |
Test results for "MCP"1 failed 8347 passed, 1376 skipped Merge workflow run. |
|
Hi, I'm the Playwright bot and I took a look at the CI failures here. 🟢 The one failure isn't caused by this PRThis is a docs-only change (a "How request interception works" section in DetailsPre-existing flake / infra
Flaky (no triage needed) — from the
Triaged by the Playwright bot - agent run |
|
|
||
| ### Headers owned by the network stack | ||
|
|
||
| Some headers are attached by the network stack right before the request is sent: `Cookie`, `Host`, `Accept-Encoding`, `Content-Length`, `Sec-Fetch-*` and a few others. This is a security boundary: an `HttpOnly` cookie, for example, is never exposed to the page. Since the route handler runs before that step, these headers are not reliably present in [`method: Request.headers`] or [`method: Request.allHeaders`], and they cannot be overridden. A `cookie` header passed to [`method: Route.continue`] is ignored in favor of the browser's cookie store. |
There was a problem hiding this comment.
Yet Cookie header is available on intercepted request, we might want to clarify that to avoid confusion.
da3553d
into
microsoft:main
Summary
Sec-Fetch-*, ...) are not visible or overridable in the handler but are visible on the response; redirects are followed by the browser and the handler runs once per chain; fulfilling with a redirect is not supported.mermaidcode blocks in doclint.References #42620