The Connection header is an HTTP instruction that determines whether a network connection stays open or closes after a request finishes. It is a "hop-by-hop" header, meaning it only manages the connection between the immediate sender and receiver, rather than the entire path between a browser and a web server. Properly managing this header ensures your website handles traffic efficiently by reusing existing connections for multiple files.
What is the Connection Header?
This header acts as a control switch for the underlying TCP connection used to load your web pages. When a browser requests an image, script, or CSS file, the Connection header tells the server whether to keep the "pipe" open for the next file or to tear it down immediately.
While it has been [widely available across all major browsers since July 2015] (MDN), its behavior changes significantly depending on the version of HTTP your server uses.
Why Connection Header matters
Managing how connections open and close directly impacts how fast a page feels to a user and how much load your server can handle.
- Improved performance: Reusing a connection eliminates the need to send extra TCP/IP packets to start and stop connections for every single file.
- Reduced latency: By keeping a connection "warm," the browser can skip the initial handshake process for subsequent requests, leading to faster resource loading.
- Resource efficiency: Using the "close" directive helps free up server memory and processing power when a client no longer needs to send requests.
- Proxy management: It tells intermediate servers (proxies) which headers to remove before forwarding a request, preventing technical errors in the data chain.
How Connection Header works
The header uses specific "directives" to signal intent between the browser and the server. This process differs based on the protocol version:
- HTTP/1.0 era: Connections were closed by default after every request. To keep them open, the client had to explicitly send
Connection: keep-alive. - HTTP/1.1 era: Stability improved as connections became persistent by default. Even so, many browsers still send
Connection: keep-aliveto ensure compatibility with older systems. - The Transaction: If a client sends
Connection: close, the server finishes the current response and then terminates the link. If the server sendsConnection: closein its response, it will shut down the link [even if the client requested to keep it open] (Server Fault).
Directives and Variations
| Directive | Impact on Connection | Best Use Case |
|---|---|---|
keep-alive |
Stays open for more requests. | Standard web browsing where multiple assets (images, JS) are needed. |
close |
Closes after the current response. | One-off requests or when the server is low on resources. |
| Header List | Removes specified headers at the first proxy. | Security or custom connection-specific instructions. |
Best practices
Check your protocol version. Do not use the Connection header if your site runs on HTTP/2 or HTTP/3. These modern protocols handle connection multiplexing differently and prohibit the use of connection-specific headers.
Support persistent connections for HTTP/1.0.
If you still support very old legacy clients, ensure your server is configured to recognize the keep-alive directive so those users do not experience extreme slowness.
Use "close" for one-time sessions.
If you know a client will only ever make one request (such as a simple API ping), use Connection: close to [free up server resources immediately] (ReqBin).
List all hop-by-hop headers.
If you use other connection-specific headers like Upgrade or Transfer-Encoding, you must list them within the Connection header so that proxies know not to forward them to the origin server.
Common mistakes
Mistake: Using the Connection header in HTTP/2. Fix: Remove these headers for HTTP/2 and HTTP/3. [Safari will fail to load a response] (MDN) if it sees a Connection header in an HTTP/2 communication.
Mistake: Assuming a request will stay open forever. Fix: Always account for timeouts. Servers and clients often set limits, such as a [timeout of 5 seconds or a maximum of 100 requests] (ReqBin) before forced closure.
Mistake: Including "end-to-end" headers like Cache-Control in the Connection header. Fix: Only list connection-specific (hop-by-hop) headers. End-to-end headers must be allowed to pass through proxies to the final destination.
Examples
Example scenario: Persistent connection request A browser wants to download multiple images from a gallery. It sends:
GET /image1.jpg HTTP/1.1
Host: example.com
Connection: keep-alive
The server agrees and keeps the pipe open for image2.jpg.
Example scenario: Closing a connection A server is under heavy load and cannot maintain extra open idle connections. It responds:
HTTP/1.1 200 OK
Content-Type: text/html
Connection: close
The browser receives the page and immediately terminates the connection.
FAQ
What is the difference between Connection and Keep-Alive headers? The Connection header is the general instruction that tells the computer to keep the link open. The Keep-Alive header provides the specific rules for that open link, such as how many seconds it should stay idle before closing.
Can a server ignore a "keep-alive" request?
Yes. If a server does not support persistent connections or lacks the resources to maintain them, it can send Connection: close in the response to override the client's request.
How does this affect my SEO tools?
Most SEO crawlers use HTTP/1.1. If your server is misconfigured to always send Connection: close, the crawler must restart the connection for every page it audits, which can slow down the crawl and make your server appear less performant than it actually is.
Is Connection: keep-alive the default? For HTTP/1.1, yes. For the older HTTP/1.0, the default is to close the connection after every request.
