How HTTP Actually Works (Requests, Headers, and Pipelines)

Team 4 min read

#webdev

#http

#networking

#tutorial

Overview

HTTP is the foundation of the web. Each time you click a link or submit a form, a small language of requests and responses travels between your browser (the client) and a server. This post breaks down the core pieces: how a request is constructed, how headers communicate meaning, and what pipelines mean for performance and real-world usage.

How an HTTP Request Travels

  • DNS resolution: your client looks up the IP address for the target domain.
  • Transport setup: a TCP connection is established; if the URL is HTTPS, a TLS handshake occurs to establish a secure channel.
  • The request line: the client sends a line like “GET /path HTTP/1.1” (or POST, PUT, etc.).
  • Headers: key-value pairs that describe the request. Examples include Host, User-Agent, Accept, and Connection.
  • Optional body: for methods like POST or PUT, the request may include a payload (JSON, form data, etc.).
  • Server response: the server replies with a status line (e.g., HTTP/1.1 200 OK), response headers, and a body (the requested resource or an error message).
  • Connection handling: the connection may be closed after the response or kept alive for reuse (keep-alive).

The Role of Headers

  • Request headers vs. response headers: headers provide metadata about the message and how it should be processed.
  • Common request headers:
    • Host: tells the server which hostname is being requested, essential for virtual hosting.
    • User-Agent: identifies the client software.
    • Accept / Accept-Language / Accept-Encoding: indicate what formats, languages, and encodings the client prefers.
    • Connection: directives like keep-alive or close.
    • Content-Type / Content-Length: for requests with a body, describe the payload.
  • Common response headers:
    • Content-Type / Content-Length: describe the response payload.
    • Cache-Control / Expires / ETag: control caching behavior and resource freshness.
    • Set-Cookie: starts a session cookie on the client.
    • Location: used in redirects (3xx responses).
  • Practical implications:
    • Headers influence caching, negotiation (content types and encodings), security (CORS, HSTS), and performance (compression via Accept-Encoding).
    • In HTTP/2 and HTTP/3, headers can be compressed (HPACK/QPACK) to reduce overhead.

HTTP Pipelines: What They Are and Why They Fell Out of Favor

  • HTTP/1.1 pipelining concept: a client can send multiple requests on a single persistent connection without waiting for responses.
  • Ordering requirement: responses must be returned in the same order as requests, which makes the server and intermediaries sensitive to head-of-line blocking.
  • Real-world pitfalls:
    • Proxies and intermediaries may mishandle or break pipelines.
    • Browsers rarely enable strict pipelining due to complexity and compatibility concerns.
  • Modern reality:
    • HTTP/2 and HTTP/3 replace pipelining with multiplexing, allowing many requests and responses to travel concurrently over a single connection without strict ordering constraints.
    • Multiplexing reduces head-of-line blocking and improves latency, especially on high-latency networks.
  • Takeaway: don’t rely on HTTP/1.1 pipelining for performance; prefer protocols that support multiplexing (HTTP/2 or HTTP/3) and optimize headers and payload sizes accordingly.

A Quick End-to-End Example

Here is a simplified look at a typical HTTP/1.1 request and the corresponding response.

Code example (HTTP-like text): GET /index.html HTTP/1.1 Host: example.com User-Agent: MyBrowser/1.0 Accept: text/html Connection: keep-alive

HTTP/1.1 200 OK Date: Tue, 15 Apr 2025 12:34:56 GMT Content-Type: text/html; charset=utf-8 Content-Length: 1372 Server: ExampleServer/1.0

...

This illustrates the fundamental exchange: the request line, headers, and optionally a body; the server’s status line, headers, and body in the response.

Practical Takeaways

  • Always include the Host header for HTTP/1.1 requests to ensure correct virtual hosting behavior.
  • HTTPS adds the TLS handshake; reuse persistent connections when possible to amortize setup costs.
  • Headers drive behavior: use proper Content-Type, Cache-Control, and Accept-* headers to optimize caching, compression, and content negotiation.
  • For modern apps, rely on HTTP/2 or HTTP/3 multiplexing rather than attempting to use HTTP/1.1 pipelining for performance gains.

Conclusion

HTTP is a simple protocol at heart but powerful in practice because of how requests, headers, and connection behavior interact across networks. While pipelining is mostly a historical curiosity, understanding the lifecycle—how requests are built, how headers convey meaning, and how modern transports multiplex traffic—helps you write better clients, design clearer APIs, and troubleshoot latency and caching issues more effectively.