Skip to content

docs(network): explain how request interception relates to the network stack - #42646

Merged
Pavel Feldman (pavelfeldman) merged 1 commit into
microsoft:mainfrom
pavelfeldman:docs-request-interception
Sep 14, 2026
Merged

docs(network): explain how request interception relates to the network stack#42646
Pavel Feldman (pavelfeldman) merged 1 commit into
microsoft:mainfrom
pavelfeldman:docs-request-interception

Conversation

@pavelfeldman

Copy link
Copy Markdown
Member

Summary

  • New "How request interception works" section in the network guide: routes run before the network stack, so headers it owns (cookies, 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.
  • Allow mermaid code blocks in doclint.

References #42620

@github-actions

Copy link
Copy Markdown
Contributor

Test results for "tests 1"

5 flaky ⚠️ [chromium-page] › page/workers.spec.ts:191 › should attribute network activity for worker inside iframe to the iframe `@chromium-ubuntu-22.04-node20`
⚠️ [chromium-library] › library/video.spec.ts:664 › screencast › should capture full viewport `@chromium-ubuntu-22.04-node22`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@firefox-ubuntu-22.04-node20`
⚠️ [webkit-page] › page/page-set-input-files.spec.ts:38 › should upload a folder `@webkit-ubuntu-22.04-node20`

51528 passed, 1246 skipped


Merge workflow run.

@github-actions

Copy link
Copy Markdown
Contributor

Test results for "MCP"

1 failed
❌ [chrome] › mcp/profile-lock.spec.ts:42 › isProfileLocked returns false after browser closes @mcp-macos-latest-chrome

8347 passed, 1376 skipped


Merge workflow run.

@github-actions

Copy link
Copy Markdown
Contributor

Hi, I'm the Playwright bot and I took a look at the CI failures here.

🟢 The one failure isn't caused by this PR

This is a docs-only change (a "How request interception works" section in network.md plus a mermaid entry in the doclint allowlist). The single red test is mcp/profile-lock.spec.ts:42 on mcp-macos-latest-chrome — a 30s timeout with no other error. The diff touches no product code and nothing the MCP profile-lock flow runs, so it can't reach this test. The tests 1 report is flaky-only (0 failed), so there's nothing to triage there.

Details

Pre-existing flake / infra

  • [chrome] › mcp/profile-lock.spec.ts:42 › isProfileLocked returns false after browser closes (@mcp-macos-latest-chrome) — timed out at 30000ms with no further error, on one bot only; every other MCP bot passed (or skipped for non-chrome). One honest caveat: this test doesn't have a prior failure to point at — across the test-results DB it's passed 2141/2141 runs (chrome 718, chromium 720, msedge 703) and this is its first-ever red, on this PR's run. So it's a first-occurrence infra timeout rather than a known repeat flake. What makes me confident it isn't this PR: the change is docs + doclint only, so there's no code path from the diff to browser profile locking, and the failure is isolated to a single macOS-chrome bot with a bare timeout signature.

Flaky (no triage needed) — from the tests 1 report

  • [chromium-page] › page/workers.spec.ts:191, [chromium-library] › library/video.spec.ts:664, [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 and :470, [webkit-page] › page/page-set-input-files.spec.ts:38 — all passed on retry. Unrelated to a docs change.

Triaged by the Playwright bot - agent run

Comment thread docs/src/network.md

### 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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yet Cookie header is available on intercepted request, we might want to clarify that to avoid confusion.

@pavelfeldman
Pavel Feldman (pavelfeldman) merged commit da3553d into microsoft:main Sep 14, 2026
44 of 45 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants