A remote WebDriver endpoint address stops authenticating after the credit-union statements portal's account password is rotated to a value containing @ and : characters. What broke?

## The parse happens before the credential is ever read An endpoint address is a string, and every layer that receives it treats it as a URL before a credential. The authority has a fixed shape: an optional user-info component, an at-sign, the host, then an optional colon and port. That grammar is why the form works at all, and why the credential is fragile in a way a password field is not. When the credit-union statements portal suite is rotated onto a password full of reserved characters and pasted straight into the address, nothing has authenticated and failed — the parse produced a different address, or none. ## What each character does - **An unescaped `@`** adds a second at-sign, and parsers then disagree about where the host begins. Java's `java.net.URI` gives up on a server-based authority: host and user info both come back null. Python's `urllib.parse` and Node's WHATWG parser split at the **last** at-sign instead, recovering the intended host and the whole password. `curl` refuses the address as a bad hostname. Nothing treats your password's tail as a host; the hazard is that one string means three different things in three neighbouring tools. - **An unescaped `:`** is legal in the user info but is also the separator between username and password. Selenium's `PasswordAuthenticator` calls `userInfo.split(":", 2)`, so everything before the **first** colon is the username and the rest is the password. A colon inside the password is safe; a colon inside the username silently truncates it and pushes the remainder into the password. - **An unescaped `/`, `?` or `#`** ends the authority early, so host and port are gone before they are read; Java's `java.net.URL` refuses it outright with a `MalformedURLException`, inside your own assembly code. - **No colon at all** is not an error. Selenium's `PasswordAuthenticatorTest` asserts that a user-info string of just a name yields that name and an **empty** password — a silent, valid-looking wrong answer. ## Why the error names the wrong layer Selenium's `ClientConfig.baseUrl` does call `toURI()` and rethrow a `URISyntaxException` as a `RuntimeException`, so a construction-time failure feels likely. It is not what happens. Java accepts the doubled at-sign, so `RemoteWebDriver` builds its client without complaint and the address looks fine until it is used. The run dies on the new-session request: Selenium's `JdkHttpMessages` concatenates the base and `/session`, and `java.net.http.HttpRequest` rejects the result with `IllegalArgumentException: unsupported URI`, because a URI with no host cannot become an HTTP request. That `RuntimeException` path is real, but only for characters a URI forbids outright, such as a space or a brace. Two things follow. The message names a URI while you hunt an authentication problem, so the obvious hypotheses — the account was revoked, the service is down, the rotation did not propagate — all point at the far side while the fault is yours. And it quotes the whole address, so the rotated password is now in cleartext in a stack trace and in whatever collects it. Selenium masks credentials in the messages it formats itself; this one is formatted below that masking, by the JDK. ## The fix, and the trap inside the fix Two honest fixes exist, and they are not equivalent: 1. **Percent-encode the reserved characters** in the user-info component as you assemble the address. It works, but it puts a correctness requirement in whatever code concatenates the string, where encoding the wrong half is easy. 2. **Take the credential out of the address.** Selenium's client configuration accepts it as data: `ClientConfig.defaultConfig().authenticateAs(new UsernameAndPassword(user, pass))`. Those are plain strings no URL parser touches, so no character in a rotated password can change the meaning of the address. The trap is precedence. Selenium's `JdkHttpClient` reads `baseUri.getUserInfo()` first and, when it is non-empty, builds a `PasswordAuthenticator` from it; only when the user info is absent does it fall back to the credentials from `authenticateAs`. Because `RemoteWebDriver` always installs the URL argument as the base URI, a well-formed address that still carries a stale `user:password@` **silently wins** over the credentials you passed in as data. "We moved the credential out of the URL" is only true once the URL itself is clean. The doubled at-sign inverts even that: with no server-based authority there is no user info to read, so the configured credentials would have been used — had the request ever been built. ## Operating rules that survive a rotation - Assemble the address from parts at run time; never store a fully-formed address embedding a credential. - If the address must carry user info, percent-encode it at assembly, once, and never by hand. - Prefer the client's credential API, then assert the endpoint you pass alongside it has no user info. - Constrain generated passwords to URL-safe characters only if you cannot avoid the embedded form; that is a workaround, not a design. - When a rotation breaks a remote run, check the shape of the address before the account. The parse is upstream of everything else. ## What a weak answer sounds like A weak answer reaches for the service: the key must be wrong, the account disabled, the fleet unreachable. A strong answer notices that the symptom appeared the moment the *string* changed, and that a URL is a grammar, not a container. Every character that means something to a parser is a character that can break the run.