What out-of-the-box behaviors does the java.net.http client provide for HTTP/2, redirects, timeouts, and authentication?

## Why defaults matter A platform HTTP client makes choices for you. Knowing `java.net.http`'s defaults prevents subtle bugs — like silently not following a redirect, or assuming HTTP/1.1 when HTTP/2 is in play. ## HTTP/2 (and fallback) **HTTP/2** is a newer version of the protocol that multiplexes many requests over one TCP connection (vs HTTP/1.1's one-request-at-a-time per connection), with header compression and server push. The Java client **defaults to HTTP/2** and **automatically falls back to HTTP/1.1** if the server doesn't support it. You can force a version: ```java HttpClient.newBuilder().version(HttpClient.Version.HTTP_1_1).build(); ``` or per request via `.version(...)` on the request builder. Multiplexing means several concurrent requests to the same host can share one connection — efficient, but it also means the connection pool behaves differently from HTTP/1.1. ## Redirects A **redirect** is a 3xx response telling the client to fetch a different URL (e.g. 301 Moved Permanently, 302 Found). The client's policy is `HttpClient.Redirect`: - **`NEVER`** — the **default**: 3xx responses are returned to you as-is; nothing is followed automatically. - **`NORMAL`** — follow redirects, *except* it will not redirect from HTTPS to HTTP (a security downgrade). - **`ALWAYS`** — follow all, including downgrades. ```java HttpClient.newBuilder().followRedirects(HttpClient.Redirect.NORMAL).build(); ``` The common gotcha: people expect redirects to be followed automatically (curl/browsers do); here you must opt in. After following, `response.uri()` gives the final URL. ## Timeouts There are **two distinct** timeouts: 1. **Connect timeout** — set on the *client*: `.connectTimeout(Duration.ofSeconds(5))`. Caps how long establishing the connection may take. If exceeded, an `HttpConnectTimeoutException` (a subtype of `HttpTimeoutException`) results. 2. **Request timeout** — set on the *request*: `.timeout(Duration.ofSeconds(10))`. Caps the overall time to receive the response. If exceeded, an `HttpTimeoutException` results (or the async future completes exceptionally with it). There is **no default** request timeout — without one, a slow server can block you indefinitely (or until the OS socket times out), so always set request timeouts in production. ## Authentication Two approaches: 1. **`java.net.Authenticator`** set on the client: `.authenticator(myAuthenticator)`. It responds to HTTP/proxy **auth challenges** (a 401/407 asking for credentials), primarily **Basic** auth. Crucially, it is **reactive, not preemptive** — it answers a challenge after a 401; it does not send credentials on the first request. 2. **Set the header yourself** — for token APIs this is the norm: ```java HttpRequest.newBuilder(uri) .header("Authorization", "Bearer " + token) .GET().build(); ``` For Basic preemptively, you Base64-encode `user:pass` into the `Authorization` header rather than relying on the `Authenticator`. ## Other built-ins worth knowing - **WebSocket**: `client.newWebSocketBuilder().buildAsync(uri, listener)` — full-duplex messaging built into the same client. - **HTTP/2 server push**: `sendAsync(req, handler, pushPromiseHandler)` lets you accept resources the server proactively pushes. - **Cookies**: not managed unless you set a `CookieHandler` via `.cookieHandler(new CookieManager())`. - **Proxy**: `.proxy(ProxySelector...)`; **SSL**: `.sslContext(...)` / `.sslParameters(...)`. - **Executor / connection pool**: shared and reused across requests on the same client. ## The headline gotchas - Redirects are **off by default**. - There is **no default request timeout** — set one. - The `Authenticator` is **reactive Basic**, not a place for Bearer tokens — add the header yourself. - HTTP/2 is the default, which changes connection-reuse behavior vs HTTP/1.1.