fix: preview proxy ERR_BLOCKED_BY_CLIENT + network-context logging#13
Merged
Conversation
…ures Failed API and preview requests now gather Chromium's view of the network — online state, the proxy resolved for the failing URL, and app/electron versions — log it under the "net" scope, and append it to the on-screen error, so a user's screenshot or log file alone distinguishes DNS, proxy, VPN, and TLS problems. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Since the preview proxy fetches upstream via Chromium's network stack, forwarding the webview's localhost Referer makes Chromium kill every subresource request (styles, scripts, images) with net::ERR_BLOCKED_BY_CLIENT, because the Referer doesn't match the .aem.page destination. Node's fetch passed it through silently, which is why this only surfaced after the proxy-aware fetch change. Strip the header like the localhost Origin already is; it also stops leaking the local proxy origin upstream. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Blank previews were undiagnosable: request starts, the 503 no-active-site path, upstream status/content-type/timing, auth-probe failures, and mid-stream body errors were all silent. Each request now logs one start line and one completion line (status, content type, site-token presence, duration), every early-exit path says why, and upstream body stream failures destroy the response instead of stalling it silently. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Forwarding the webview's Sec-Fetch-Mode: cors upstream makes Chromium's net.fetch reject the request instantly with net::ERR_INVALID_ARGUMENT — module scripts broke while no-cors stylesheets survived. Fetch metadata describes the webview's request context, not the proxy's; Chromium sets its own sec-fetch-* on the upstream request, so never forward them. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
|
🎉 This PR is included in version 1.6.4 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
With the proxy-aware fetch from #11, the preview view broke — every subresource fails:
Root cause (verified empirically)
The preview proxy forwards the webview's request headers upstream, including
Referer: http://127.0.0.1:<port>/…. Chromium's network stack (net.fetch) kills any request whoseRefererdoesn't match the destination withnet::ERR_BLOCKED_BY_CLIENT. Node's fetch passed the header through silently, which is why this only surfaced after #11. It explains the exact symptom: the page itself loads (no Referer on navigation), every subresource dies (they all carry one).Probe against the real endpoint with the project's Electron:
Referer: http://127.0.0.1:3000/…Sec-Fetch-*onlyChanges
Refererin the preview proxy's forwarded request headers (same treatment as the localhostOrigin, which EDS already rejected with 403). Also stops leaking the local proxy origin upstream.netscope and appended to the on-screen error, so a user's screenshot alone distinguishes DNS, proxy, VPN, and TLS problems. It's what made this bug diagnosable from the log line above.Testing
Referer(mirrors the existing Origin-strip test)npm run lintandnpm testgreen (206 tests)🤖 Generated with Claude Code