Skip to content

Browser tests: route guest HTTP through the configured CORS proxy.#880

Closed
brandonpayton wants to merge 1 commit into
mainfrom
fix/browser-cors-proxy
Closed

Browser tests: route guest HTTP through the configured CORS proxy.#880
brandonpayton wants to merge 1 commit into
mainfrom
fix/browser-cors-proxy

Conversation

@brandonpayton

@brandonpayton brandonpayton commented Jul 11, 2026

Copy link
Copy Markdown
Member

What #907 already landed

#907 put the production BrowserKernelOptions.corsProxyUrl path on main: the option already crosses the main-thread/worker protocol and reaches TlsNetworkBackend. This PR does not merge the old runtime commit verbatim.

What remains here

  • configure the browser test runner with its existing same-origin Vite proxy
  • assert that BrowserKernel forwards the option in its init message
  • run Wget in Chromium against a local cross-origin server with no CORS headers and no service-worker controller
  • document where the explicit proxy fits into the browser networking path

The Chromium test uses the normal guest socket and Wget path. The local upstream receives exactly /probe, which keeps the regression deterministic and avoids an external network dependency.

What was removed

The stale copies of the BrowserKernel option, worker protocol field, worker backend setup, and TLS backend option documentation were removed because #907 already landed that production behavior. There are no production host-runtime changes in this diff. Node is unchanged.

ABI and package artifacts

This does not change the kernel/process ABI, generated ABI evidence, Wasm exports, package metadata, package revisions, release archives, indexes, or VFS image contents. The test uses the existing resolver-managed Wget artifact. No artifact revision is needed.

Validation

Run through scripts/dev-shell.sh:

  • host typecheck: passed
  • focused host/test/browser-kernel.test.ts: 13 passed
  • full host Vitest: 166 files passed; 1,357 tests passed; 2 expected failures and 42 skips
  • browser asset check: 92 imports resolved
  • focused Chromium proxy regression: 1 passed
  • non-slow Chromium suite: 52 passed, 4 skipped
  • ./run.sh browser --host 127.0.0.1 --port 5498 --strictPort: Vite started; the Kandelo page and test-runner page loaded, and the proxy rejected a request without a target with HTTP 400

Not run locally: Firefox, WebKit, slow browser tests, libc/POSIX/Sortix suites, ABI snapshot check, package rebuild/publish checks, or performance benchmarks. Those suites are outside this test-only browser diff, and this PR makes no performance claim.

@brandonpayton

Copy link
Copy Markdown
Member Author

CI triage: the failed staging run did not reach this PR's test suites. test-gate-prepare failed while materializing the unchanged ABI-16 baseline in --fetch-only mode: the published index entries for lamp, node-vfs, shell, and wordpress each have a cache_key_sha that no longer matches the current checkout. The job resolved 64/68 packages, then exited before the browser/host test matrix.

This is independent of the CORS-proxy code path, but it remains a required CI gate. The PR's focused evidence is still the local host tests/typecheck/ABI check plus the exact Wget Chromium HTTPS/refusal run described above. The staging gate should be rerun after the binary baseline is repaired or the ABI-18 package rebuild becomes the selected baseline.

@brandonpayton

Copy link
Copy Markdown
Member Author

ABI 18 history-only rebase update:

  • old head: 35f040eb0e99244707f342b21790e3a3270d07fc
  • new exact head: 13c66dc5856ee12eb8a2e40709b3b1b4abfa87fc
  • direct parent/current main: 2c083e143618e4974a637b649e6221c64f0dd936
  • stable patch ID unchanged: 3dfea8dd51bc1f0ce5a971110beedb08b4237a47
  • one-commit range-diff is exact (35f040eb0 = 13c66dc58)
  • file set/stat remains 7 files, +26/-5
  • merge tree equals the rebased head; git diff --check passes; worktree and remote are clean

The rebase was conflict-free and changed no behavior or release-ledger data. The old ABI 16 composite-ledger failure belongs only to the superseded head. New staging run 29179249989 and browser smoke run 29179250021 are now evaluating the exact ABI 18 head. No local runtime suite is claimed for this history-only operation.

@brandonpayton

Copy link
Copy Markdown
Member Author

Before reconstructing this PR directly on current main, I recorded the existing head as 13c66dc5856ee12eb8a2e40709b3b1b4abfa87fc. The branch will be rewritten with an exact --force-with-lease so the stale runtime plumbing can be dropped while preserving the focused browser-test work.

Configure the browser test runner with its same-origin Vite proxy and keep a Chromium Wget regression for pages without a service-worker controller. Assert that BrowserKernel forwards the existing option and document the browser transport boundary.
@brandonpayton
brandonpayton force-pushed the fix/browser-cors-proxy branch from 13c66dc to 79dd37d Compare July 13, 2026 18:23
@brandonpayton brandonpayton changed the title Let browser guests use an explicit CORS proxy Browser tests: route guest HTTP through the configured CORS proxy. Jul 13, 2026
@brandonpayton

Copy link
Copy Markdown
Member Author

Closing this focused source PR because #934 now carries the unique browser test-runner wiring, proxy assertion, integration coverage, and non-duplicated documentation at exact green head 260d75d5adc31b327f5591229dbfbb287d395fd6. The runtime plumbing already on main through #907 was deliberately excluded. The full staging and browser gates passed. This is not a claim that this branch was merged verbatim.

@brandonpayton
brandonpayton deleted the fix/browser-cors-proxy branch July 14, 2026 02:43
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.

1 participant