In an HTTP challenge such as `WWW-Authenticate: Basic realm="Reports", charset="UTF-8"`, what do the realm and charset parameters actually control, and how should a password containing a character like 'ö' be encoded?

## The realm parameter Every challenge in the HTTP authentication framework may carry a `realm`. It is a quoted string naming a **protection space**: the set of resources on an origin that share one credential set. A client that has successfully authenticated to `https://api.example.com` with `realm="Reports"` may reuse those credentials for any other URI on that origin that presents the same realm, without waiting for a new 401. That is the whole of its function. Three practical consequences follow: - **It is a cache key, not a control.** Nothing about the realm restricts access. Authorization decisions live in the server's logic; the realm only tells the *client* which stored credential applies. Two servers can use the same realm string and share nothing. - **It is user-visible.** Browsers render it in the Basic login dialog ("api.example.com asks: Reports"). So it must be meaningful to a human and free of internal hostnames, ticket numbers, version strings or anything that helps an attacker fingerprint the system. Some browsers also strip or ignore it to defeat phishing text injected via the realm — never rely on it to convey instructions. - **Comparison is exact.** The realm value is compared as a case-sensitive string, so `"Reports"` and `"reports"` are different protection spaces and will cause a client to re-prompt. Because Basic is normally sent preemptively by API clients, many services return a realm that is essentially decorative. It still matters for browsers and for HTTP libraries that implement the challenge-then-retry flow with a credential store. ## Why charset exists The original Basic definition said to base64 the string `user:password` but never said which character encoding turns that text into bytes. As long as everything was ASCII, nobody noticed. The moment a password contained `ö`, `é`, `ü`, a Cyrillic letter or an emoji, clients diverged: browsers on Windows used the system codepage, some libraries used ISO-8859-1, others UTF-8. The same typed password produced different base64, so the server's comparison failed — the classic bug where a user can log in from one browser but not another, or can log in on their laptop but not their phone. RFC 7617 fixes this by defining exactly one new parameter, `charset`, whose only allowed value is `UTF-8` (case-insensitive as a token, but no other value is defined; anything else must be ignored). The challenge `WWW-Authenticate: Basic realm="Reports", charset="UTF-8"` is a hint telling the client: encode the credentials in UTF-8 before base64. Concretely, for user `jörg` and password `pa55`: - UTF-8 bytes → base64 `asO2cmc6cGE1NQ==` - ISO-8859-1 bytes → base64 `avZyZzpwYTU1` A server that decodes as UTF-8 sees the first as `jörg:pa55` and the second as invalid UTF-8 (or as mojibake if it decodes leniently). ## What servers should do 1. **Always decode as UTF-8**, and advertise `charset="UTF-8"` in the challenge. Do not try to sniff the encoding. 2. **Reject invalid UTF-8** rather than substituting replacement characters — silently mapping bad bytes to U+FFFD can collapse distinct credentials onto one string. 3. **Normalize.** Unicode lets `ö` be one code point (U+00F6) or two (`o` + U+0308). They look identical and users cannot tell which their keyboard produced. Apply NFC normalization — the PRECIS framework (RFC 8265) defines profiles for usernames (`UsernameCaseMapped`) and passwords (`OpaqueString`, which normalizes to NFC and preserves case) for exactly this purpose. Do the same normalization at registration time and at verification time, or users will be locked out of their own accounts. 4. **Compare in constant time** once you reach the secret comparison, and remember the parse rule: split the decoded string at the first colon only. ## Client and tooling notes `curl -u` encodes whatever bytes your shell hands it, so a UTF-8 terminal yields UTF-8 credentials. Older Windows tooling may not. If you are debugging a "password works here, fails there" report with non-ASCII characters, decode the actual header from both clients and compare the bytes — the difference is almost always the encoding or the normalization form, not the password. ## Interview framing The short version to say out loud: realm names the protection space for credential caching and is user-visible, carrying no security; charset exists only because the original spec left the byte encoding undefined, `UTF-8` is its sole value, and non-ASCII credentials additionally need Unicode normalization on the server to be reliable.