= HTTP persistent connection
{c}
An <HTTP persistent connection> carries more than one <HTTP request>/<HTTP response> exchange over the same connection. <HTTP 1.1> uses persistence by default unless its connection rules indicate closure. Reusing the connection avoids establishing a separate connection for every exchange.<HTTP 1.1 (RFC 9112)>[§9.3, persistence default and determination from protocol version and Connection]{ref}
For a sequential example, a client retrieves `/color` and reads a response with `Content-Length: 4` followed by `blue`. It then requests `/shape` on the same connection and reads `Content-Length: 6` followed by `circle`. These are two distinct requests and two distinct responses, each with its own control information and <HTTP message framing>. Neither resource name nor method is inherited merely because the connection is reused.
This example relies on being able to finish the first message without closing the connection. To retain persistence, the message lengths must be self-defined rather than delimited by closure. A server must read the complete request body or close the connection after responding; otherwise leftover body bytes could be mistaken for a new request. A client likewise must consume the complete response body before reusing the connection.<HTTP 1.1 (RFC 9112)>[§9.3, self-defined length and complete request/response-body requirements]{ref}
`Connection: close` signals that the connection will close after the current response. Persistence is not a promise of an unlimited lifetime: a connection can also close unexpectedly. Whether an outstanding operation can be retried automatically depends on its semantics, particularly <HTTP idempotence>, rather than on the fact that the connection had previously been reusable.<HTTP 1.1 (RFC 9112)>[§9.6, close option; §9.3.1, asynchronous closure and retry]{ref}
Persistence also does not require sending requests before earlier responses arrive. That additional option is <HTTP pipelining>; in <HTTP 1.1>, the corresponding responses must retain request order. The sequential example uses persistence without pipelining.<HTTP 1.1 (RFC 9112)>[§9.3.2, Pipelining]{ref}
Back to article page
