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 session-creation URL rewriting and shared e2e URL builders used by BiDi/CDP tests; scope is limited to scheme/host correctness with regression tests, but wrong logic would break remote automation connectivity.

Overview
Fixes WebDriver-BiDi and CDP clients failing behind the hypeman TLS ingress (https/wss on :9224 and :9222) while leaving Docker plaintext (http/ws) behavior unchanged.

In chromedriverproxy, POST /session responses now rewrite capabilities.webSocketUrl to wss:// when the client reached the proxy via TLS (X-Forwarded-Proto: https or r.TLS), via new clientWSScheme and an updated rewriteWebSocketURL. A regression test covers the forwarded-proto path.

E2e helpers align with the same transport split: ChromeDriverAddr strips any URL scheme (not only http://), ChromeDriverWSURL chooses ws vs wss from an https:// ChromeDriver base URL, and fetchBrowserWebSocketURL uses https for /json/version when CDPURL() is wss://.

^{Reviewed by Cursor Bugbot for commit e4d51ec. 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