In a remote WebDriver endpoint address, what do the scheme, user info, host, port and path each decide?

## The five parts, and what each one settles A remote run has no browser to launch; it has an address. That address is the whole configuration surface for "where does this run", so it repays reading slowly. Written out, the form is: ``` scheme :// [ user : password @ ] host [ : port ] / path ``` Each part answers a different question, and confusing two of them is the most common way a first remote run fails. - **Scheme** — `http` or `https`. Every WebDriver command is a separate request, so the scheme is not a one-time choice at connect; it is the transport for every round trip the suite makes. - **User info** — the optional `user:password@` between the scheme and the host. This is where an account credential rides when a service expects it in the address. - **Host** — the front door. On a rented fleet this is a router, not the machine your browser will run on. - **Port** — which listener on that host. - **Path** — which service behind that door answers WebDriver, and where your base ends and the protocol's own path segments begin. ## Scheme and user info The scheme decides encryption for the whole session, because there is no separate "connection" to secure once and forget. If the credit-union statements portal suite talks to a fleet over an unencrypted scheme, every command it sends and every response it reads crosses in the clear, for the lifetime of the run. The user-info component is the part most people meet first and understand last. Ggr's own quick start publishes exactly this shape — `http://test:test-password@localhost:4444/wd/hub` — and Ggr is unmaintained by its own README, but the form it demonstrates is everywhere, including on hosted providers. Selenium's client takes it seriously: `JdkHttpClient` reads the base URI's user info and, when it is non-empty, builds a `PasswordAuthenticator` from it, so to the client the address genuinely *is* the credential. ## Host and port: a door, not a desk The instinct is to read the host as the computer running your browser. On anything routed it is not. The host and port name whatever accepts the new-session request; a router, a balancer or a provider's front end then chooses a machine behind it. That is specified behaviour, not a quirk — the W3C WebDriver specification distinguishes an **intermediary node**, which may route a request onward, from the **endpoint node** that actually runs the browser. The practical consequence is that "which host" and "which browser machine" are two different facts, and only the first is in your address. ## Path: which service answers, and where your base stops The path is where the most avoidable mistakes live, because different servers publish different bases: - Ggr, unmaintained by its own README, points clients at `/wd/hub` in its quick start, which says to use it "in the same way you do for Selenium Hub". - Selenium Grid answers at the **root** — and also under `/wd/hub`, because its `TemplateGridServerCommand` builds a hub route that registers the same handlers beneath that prefix as well. - A deployment behind a reverse proxy adds a prefix of its own with Grid's `--sub-path` flag. `docker-selenium` surfaces that as `SE_SUB_PATH`, described in its variable table as "a sub-path that should be considered for all user facing routes on the Hub/Router/Standalone". With a sub-path set, the routes exist beneath it *as well as* at the plain positions. Below whatever base you wrote, the client appends the protocol's own segments itself. You supply the base and nothing more; adding a segment the client will also add is how a suite ends up requesting a doubled path that nothing serves. | part | decides | does **not** decide | |---|---|---| | scheme | whether each command is encrypted | which browser you get | | user info | which account the request is made as | where the request goes | | host and port | which front door accepts the request | which machine runs the browser | | path | which service on that host answers | anything below your base | ## Getting it wrong, and what it looks like 1. **Adding the protocol's own segments to your base.** The client appends them, so the request goes to a path that does not exist. 2. **Omitting a base the server requires**, or supplying one it does not use — the same class of mistake, mirrored. 3. **Reading the host as the browser machine**, then trying to reason about hardware from an address that says nothing about hardware. 4. **Leaving the user info in a value that gets logged or committed**, because it looks like part of an address rather than like a secret. 5. **Assuming a port implies a scheme.** They are independent; a service on an unusual port may still be encrypted, and one on a familiar port may not be. A useful habit: keep the address in one place, built from parts, and be able to say out loud what each of the five parts is doing. If any part is there because it was copied from an example and nobody knows what it settles, that is the part that will fail on the day the deployment changes.