fix(e2e,chromedriverproxy): WebSocket/CDP scheme over a TLS-terminating ingress

[rgarcia]

ChromeDriver BiDi and CDP over a TLS-terminating ingress (the hypeman :9224/:9222 ingresses; serve https/wss) were broken because the WebSocket/CDP URLs used the wrong scheme. Docker is plaintext (http/ws) so it never showed there. Validated in kernel-images-private #237: the full e2e suite (incl. all 5 TestBidi* and TestCDPProxyReconnect) now passes against the staging hypeman host over Tailscale.

Fixes

1. server/e2e/container.go — ChromeDriverAddr only stripped http:// (returned https://host:9224 with scheme attached); ChromeDriverWSURL hardcoded ws:// (→ malformed ws://https://host:9224/session). Now strip any scheme and pick ws/wss from the ChromeDriver URL's transport.
2. server/lib/chromedriverproxy/proxy.go — rewriteWebSocketURL kept chromedriver's ws:// scheme, so the webSocketUrl from POST /session was unreachable through the TLS ingress. New clientWSScheme(r) returns wss when X-Forwarded-Proto: https (Caddy ingress) or r.TLS != nil; docker keeps ws. + regression test.
3. server/e2e/e2e_cdp_reconnect_test.go — fetchBrowserWebSocketURL hardcoded http:// for the CDP /json/version probe (fails against the TLS :9222 ingress). Derive the scheme from the CDP URL's transport (wss → https).

🤖 Generated with Claude Code

---

Note

Medium Risk
Touches ChromeDriver session response rewriting and e2e URL construction; incorrect scheme logic would break remote BiDi/CDP but changes are narrowly scoped with new regression tests.

Overview
Fixes BiDi and CDP when traffic goes through the hypeman TLS ingress (https/wss on :9224/:9222). Plain Docker http/ws behavior is unchanged.

ChromeDriver proxy — On POST /session, rewriteWebSocketURL now sets capabilities.webSocketUrl to wss:// when the client reached the proxy via TLS (X-Forwarded-Proto: https / r.TLS), instead of leaving ChromeDriver’s internal ws:// URL. New clientWSScheme handles comma-separated forwarded proto values. Regression test added.

E2E helpers — ChromeDriverAddr strips any URL scheme (not only http://); ChromeDriverWSURL picks ws vs wss from the ChromeDriver base URL. fetchBrowserWebSocketURL uses https for /json/version when CDPURL() is wss://.

^{Reviewed by Cursor Bugbot for commit ae8abde. Bugbot is set up for automated code reviews on this repo. Configure here.}

[firetiger-agent]

Created a monitoring plan for this PR.

What this PR does: Fixes WebDriver BiDi connections that were broken when accessed through the Hypeman TLS-terminating ingress — users automating with the BiDi protocol over the secure :9224 endpoint can now establish sessions successfully.

Intended effect:

• webSocketUrl scheme in POST /session response: baseline was ws:// (wrong, unreachable through TLS ingress); confirmed working if wss:// is returned when X-Forwarded-Proto: https is present — directly verified by the new regression test TestHandler_PostSession_WSSchemeFromForwardedProto in CI.
• Docker/plaintext path: baseline unchanged (ws://); confirmed working if Docker-backend BiDi tests (TestBidiHTTPSession, TestBidiPuppeteer, TestBidiVibium, TestBidiSelenium) continue to pass in CI.

Risks:

• Docker-path regression — Docker BiDi tests in CI; alert if any of TestBidiHTTPSession / TestBidiPuppeteer / TestBidiVibium / TestBidiSelenium fails post-merge.
• X-Forwarded-Proto header absent at ingress — would silently fall back to ws:// (original broken state); no in-VM OTEL signal exists, but recurrence surfaces as BiDi session failures for users on the Hypeman ingress. Confirm Caddy ingress header injection is in place on first post-deploy BiDi session attempt.
• POST /browsers 500 spike — baseline 0–2/hr; alert if sustained >10/hr for 2+ consecutive hours post image rollout (check opentelemetry/logs/api error count by hour).

Status updates will be posted automatically on this PR as monitoring progresses.

View monitor

[tnsardesai]

reviewed — clean, well-scoped fix with a focused regression test, and the docker plaintext path stays untouched via the "" scheme sentinel. lgtm. one thing worth a look:

Questions

• server/lib/chromedriverproxy/proxy.go:192 — X-Forwarded-Proto can be comma-separated (https, http) when a request traverses multiple proxies. r.Header.Get returns the raw first header value, so EqualFold(proto, "https") won't match "https, http" and falls through to "ws" — silently reintroducing the bug this PR fixes. worth confirming the Caddy ingress only ever sets a single value; if there's any doubt, splitting on , and taking the first token is cheap insurance.

[rgarcia]

Thanks @tnsardesai — good catch. Fixed in ae8abde: clientWSScheme now splits X-Forwarded-Proto on , and uses the first (client-facing) token before comparing, so a multi-proxy "https, http" value still yields wss. Added a "https, http" case to TestHandler_PostSession_WSSchemeFromForwardedProto. (Mirrored the same fix into the private hypeman-e2e PR.)