Post-Connect Rerouting

## The reply is not an echo of the request When a new session succeeds, the remote end sends back a capability map describing the session it actually created. That map is **not** a copy of what you sent. Selenium's `RemoteWebDriver.startSession` reads the response payload into a fresh `MutableCapabilities` and assigns it over the driver's own field, so `getCapabilities()` answers with the reply. Anything an intermediary added, changed or deleted on the way back is visible there and nowhere else. For a suite driving a live-auction bidding screen, the consequence is that the address you keep talking to beyond plain commands is the far side's choice, not your configuration. ## Why an intermediary cannot return the endpoint's own address The specification defines an **endpoint node**, the last hop implemented by the user agent, and an **intermediary node**, a proxy implementing both halves of the protocol. It then binds them: all remote end node types must be *black-box indistinguishable* from a remote end, from the local end's point of view. That rule is what forces the rewrite. The browser's sockets listen inside the provider's or cluster's own network — a container address, a private host, a port nobody published — so returning them verbatim would be honest and useless. The intermediary returns an address on **itself**, on a path it owns, and proxies whatever you open there through to the real one. ## What Selenium Grid actually rebuilds In `LocalNode`, `createExternalSession` assembles the capabilities the client will see, and a helper named `rewrite` builds each address. It keeps the public grid URI's user info, host and port; swaps `http` for `ws` and `https` for `wss`; and **prepends that URI's own normalised sub-path** to a `/session/<sessionId>/se/...` suffix, rather than discarding a prefix a reverse proxy put there. So: | part of the address | what happens to it | |---|---| | scheme | becomes a WebSocket scheme | | host and port | taken from the public grid URI | | user info | copied across unchanged, credential and all | | path | the grid URI's sub-path, then a Grid-owned `/session/<id>/se/...` suffix | The user-info row is the one with teeth. Point a Grid at `https://user:[email protected]/` and the `se:vnc` it returns is `wss://user:[email protected]/session/<id>/se/vnc` — a Grid test asserts that exact string, credential included, because the address has to stay dialable. The returned map is therefore a **secret-bearing object**, not a diagnostic blob. Selenium says so four lines above the rewrite, where it deletes the client-advertised `se:remoteUrl` rather than echo it, and any embedded credentials, into the session-created log line. It ships `maskUrlCredentials` for the rest. The node's real addresses are meanwhile preserved for the Grid to dial: - `se:vncLocalAddress` keeps the node-internal live-view address and is not rewritten. - `se:gridWebSocketUrl` keeps the browser's own bidirectional socket. - `ProxyNodeWebsockets` reads those two when a client connects to the live-view or bidirectional path, and opens the upstream socket for it. It matches four public paths in all — those two plus the DevTools bridge and a forwarding path — and resolves upstream addresses from more sources than these two, the browser's own debugger address inside the vendor options among them. A second Grid test pins the path: a grid URL served under a reverse-proxy prefix returns `se:vnc` and `se:cdp` beginning with that prefix, not with `/session`. Build one by hand and you are right only where there is no prefix. ## The same idea, a different project Selenoid — which, like every Aerokube repository here, declares itself unmaintained in its own README — implements the identical mechanism with its own vocabulary. Its `processBody` function injects into `value.capabilities` a `se:cdp` entry built as `ws://<host>/devtools/<sessionId>/`, where `<host>` is the `Host` header from **your** request, and its own test dials the result. Two things follow: - The key name is shared with Selenium Grid, but the path, the port behaviour and the proxying code are Selenoid's own. A key name tells you nothing about who wrote it. - Built from the header you sent, the address is reachable by whatever name you used. ## Reading it in practice On a hosted provider the mechanism is the same though nothing about it is inspectable: it accepts a session on a public address, runs the browser where you cannot route, and hands back addresses on itself. The discipline is small and cheap: 1. Record what came back once, at session start — the **key names**. They are the evidence of what the far side agreed to and carry no secret. Log an address only after masking its user info. 2. Take every secondary address from the reply, never composing one from the endpoint you configured. 3. Read the returned authority as the **grid's**, not yours. User info, host and port all come from that one configured URI and move as a unit, so they equal what you dialled only when the grid advertises the address you dial — configure another port on the same host and the reply names it. Scheme and path differ by construction. 4. Treat a missing entry as an answer in its own right: no such channel, and still a session. Whether that is a refusal or the consequence of never asking is settled by your request, not by the reply. The rule is one sentence. **What you connected to decides what you keep talking to, and it tells you in the reply.**