Implement HTTP/1.1 Persistent Connections (Keep-Alive)

Topic Overview

Persistent Connections

HTTP/1.1 defaults to keep-alive: one TCP connection on port 80 serves multiple requests. For example, a browser fetches /index.html, then /style.css, then /logo.png over the same socket without repeating the three-way handshake.

Framing with Content-Length

The client must know where each response ends:

• Content-Length: 1234 tells the client to read exactly 1234 bytes
• Without it, the client reads until the connection closes
• Transfer-Encoding: chunked is the alternative for dynamic content

Either side can terminate with Connection: close.

Connection Lifecycle

1. Client opens TCP to 192.168.1.10:80
2. Client sends request with Connection: keep-alive
3. Server responds with body and Content-Length
4. Connection stays open for the next request
5. Either side sends Connection: close to end

Pipelining (sending multiple requests before reading responses) was part of HTTP/1.1 but rarely used in practice because head-of-line blocking on TCP made it risky. Modern browsers open several parallel connections to the same host on port 443 instead of pipelining on one socket.

Why This Exercise

This task requires you to handle multiple requests on one connection. The Slowloris attack from 2009 abused this lifecycle by opening many keep-alive connections and trickling headers slowly to exhaust server connection pools. Production configs like nginx's keepalive_timeout and Apache's KeepAliveTimeout tune the same Connection header behavior you implement here on port 80.

Write a C program that simulates the connection-lifecycle state machine of an HTTP/1.1 keep-alive server, processing a pipelined stream of requests read from stdin.

Input: HTTP requests in wire format separated by blank lines: each request is a request line (e.g. GET /index.html HTTP/1.1) followed by header lines. The last request may end at EOF without a trailing blank line.

For each request, decide whether the connection stays open after the response, per RFC 9112 section 9.3:

• A Connection header containing the close token closes the connection after that response
• Otherwise, HTTP/1.1 requests default to persistent
• Otherwise, HTTP/1.0 requests close unless the Connection header contains the keep-alive token Header names, values, and connection tokens are case-insensitive; a Connection value may be a comma-separated token list (e.g. keep-alive, upgrade)

Output:

• One line per processed request: req=N keep-alive or req=N close (N is 1-based)
• Once a request closes the connection, stop: any requests queued after it are never served
• Final line: requests=N: total requests served on the connection

Example: an HTTP/1.0 request with no Connection header is served and immediately closes, so requests=1 even if more requests follow in the stream.