Request Timeouts in Java HTTP Clients

Client timeouts place upper bounds on how long an HTTP operation can wait. Common categories include connection establishment, reading response data, and an overall request deadline.

A connect timeout limits how long the client waits while establishing a connection to the server. It is useful when a host is unreachable or the network path cannot establish the connection promptly.

A read timeout limits how long the client waits for data after the connection has been established. Depending on the HTTP client, this may apply between successful reads rather than to the entire response transfer.

An overall request timeout is a broader deadline for the complete operation. It can prevent a request from consuming resources indefinitely even when individual connection and read operations each make progress.

Timeout behavior depends on the Java HTTP client and its configuration. In an interview, distinguish the timeout categories and explain that a timeout is a failure boundary, not a guarantee that the server stops processing the request.

Key points

• Connect timeout bounds connection establishment.
• Read timeout bounds waiting for response data.
• An overall timeout can bound the complete request.
• Timeout exceptions should be handled according to whether retrying is safe.
• Exact semantics depend on the HTTP client implementation.

Interview questions

What is a connection timeout?

A connection timeout limits how long an HTTP client waits to establish a connection. If the connection cannot be established within that period, the client fails the operation. It mainly protects the application from spending too long on an unreachable or unavailable destination.

What is a read timeout?

A read timeout limits how long the client waits for response data after the connection is established. It protects a client from a server or network path that stops delivering data. Its exact behavior depends on the HTTP client implementation.

Why configure both connect and request timeouts?

They protect different phases of the operation. A connection timeout prevents excessive waiting before communication is established, while an overall request timeout limits how long the complete operation may consume resources. Using both can make failure behavior more predictable, provided their values reflect the application's latency requirements.

Should an application retry a timed-out HTTP request?

Not automatically. A timeout tells the client that its waiting limit was exceeded, but the server may have received and even completed the request. Retrying is safer for operations designed to be idempotent, or when the application has an appropriate idempotency mechanism. Retry policies should also use limits and backoff to avoid amplifying an outage.

Does a client-side timeout stop the server from processing the request?

No. A client timing out means the client stopped waiting according to its configured policy. The server may still be processing the request, or it may already have completed it. This distinction matters when deciding whether a timed-out operation can safely be retried.