HTTP/1.1 Fundamentals
Methods, headers, status codes, keep-alive, content negotiation, caching headers, chunked transfer encoding, and the request-response cycle. The protocol that defined the web.
Beginner14 min
HTTPProtocol
Loading lesson…
Methods, headers, status codes, keep-alive, content negotiation, caching headers, chunked transfer encoding, and the request-response cycle. The protocol that defined the web.
HTTP/1.1 is the protocol that still carries the vast majority of web traffic. Every API call, every page load, every image fetch begins as a plain-text request sent over a TCP connection. Understanding the wire format - methods, status codes, headers - is essential for debugging, security testing, and performance optimisation.
HTTP/1.1, standardised in RFC 2616 (now RFC 7230-7235), is a text-based request-response protocol. Every interaction starts with the client opening a TCP connection to the server, sending a request line followed by headers and an optional body, and receiving a status line with headers and a body in return.
The request line has the simplest grammar in all of computing: METHOD path HTTP/1.1. The method tells the server the intent - GET retrieves a resource, POST submits data, PUT replaces a resource, DELETE removes one. PATCH applies a partial update, HEAD fetches only the headers, and OPTIONS discovers what methods are supported.
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: curl/8.0
Accept: text/html,application/xhtml+xml
Accept-Language: en-GB,en;q=0.5
Connection: keep-aliveStatus codes are grouped into five classes: 1xx (informational, the request is being processed), 2xx (success - 200 OK, 201 Created, 204 No Content), 3xx (redirect - 301 Moved Permanently, 302 Found, 304 Not Modified), 4xx (client error - 400 Bad Request, 401 Unauthorised, 403 Forbidden, 404 Not Found, 429 Too Many Requests), and 5xx (server error - 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable).
Headers are the nerve system of HTTP. Content-Type tells the client how to interpret the body. Content-Length tells it how many bytes to expect. Accept lets the client negotiate the response format - the server uses this for content negotiation. Authorisation carries credentials (often a Bearer token or Basic auth). Cookie carries session state. Cache-Control manages caching behaviour. User-Agent identifies the client software.
Chunked transfer encoding (Transfer-Encoding: chunked) allows the server to start sending a response before it knows the total size. Each chunk is prefixed with its length in hex; the transfer ends with a zero-length chunk. This is critical for streaming responses and dynamic content.
Use the simulator below to construct raw HTTP requests, choose methods and URLs, and inspect the full request-response cycle. Toggle keep-alive on and off to see how the Connection header changes.
GET / HTTP/1.1
Host: example.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (X11; Linux x86_64)
Accept: text/html,application/xhtml+xml
Accept-Language: en-GB,en;q=0.5
Name: Value pair terminated by \r\n; an empty line separates headers from the body.HTTP/1.1 (RFC 7230-7235) is still the protocol that the majority of the web runs on. When you debug a failing API call, you are reading an HTTP/1.1 message. When you test for security vulnerabilities, you are crafting HTTP/1.1 payloads. The 99% of API calls that look like "just HTTP" are HTTP/1.1. Even HTTP/2 and HTTP/3 are optimisations on top of the same semantic model - methods, status codes, headers, and bodies all work the same way.
Understanding the wire format is essential for performance optimisation. Every extra round trip, every large header, every connection that could have been reused is a cost you can measure and fix. Tools like cURL, curl, and browser DevTools all expose the same underlying HTTP/1.1 conversation.
Because HTTP/1.1 is a plain-text protocol, it is vulnerable to eavesdropping and tampering - which is why HTTPS (HTTP over TLS) is mandatory in production. Headers like Authorisation and Cookie carry sensitive data; they must never be sent over an unencrypted connection.
Request smuggling is an HTTP/1.1-specific attack that exploits discrepancies in how front-end and back-end servers parse Content-Length and Transfer-Encoding headers. An attacker can craft a request that one server interprets as a single request and another interprets as two, potentially poisoning the next user's response. Parameterised input handling and consistent header parsing are the primary defences.
1.What does the status code 404 indicate?
2.What is the purpose of the Connection: keep-alive header?
3.Which header does a client use to tell the server what response format it prefers?