HTTP Status Codes and Error Handling
HTTP responses follow a three-part structure: status line, headers, blank line, and body.
The File Is Not Sent Alone
When a program connects to a web server and requests a file, the server does not simply send the file data by itself. It sends a structured HTTP response. The response begins with information about the result and the document, then marks where that information ends, and finally supplies the actual file content. Reading the response in the right order is the foundation of reliable HTTP parsing and error handling.
What do you think happens?
A client reads an HTTP response from top to bottom. What should it encounter before the document body?
Reveal answer
Answer: A status line, headers, and a blank-line delimiter
The response is structured so that the status line comes first, headers follow it, a blank line separates the headers from the body, and the body contains the actual file content.
Response Layout
An HTTP response has a predictable order. First comes the status line, which communicates the response status. Next come the headers, which provide metadata about the document as key-value pairs. Then comes a blank line. That blank line is not decorative: it is the delimiter that tells the client that the header section has ended. After it comes the body, containing the actual file content.
A Response Read Step by Step
Locating the Body
A client receives a response containing a status line, several header key-value pairs, a blank line, and document text. Which part should the client treat as the body?
Find the beginning: The first component is the status line. It gives the client the response status before the document metadata appears.
Read the metadata: The client reads the headers as key-value pairs. These pairs describe the document and other response information.
Find the delimiter: The client identifies the blank line after the headers. This is the boundary between metadata and file content.
Read the body: The content after the blank line is treated as the response body, or the actual file content.
The body begins immediately after the blank line that ends the header section.
Header Key-Value Pairs
An HTTP header is a key-value pair that describes the document or supplies other response metadata. The key identifies the kind of information, and the value supplies the corresponding information. A client interprets these pairs before processing the body.
| Header | What it describes |
|---|---|
| Content-Type | The type of the document or content |
| Content-Length | The length of the document or content |
| Server | Information about the server |
| Date | Date information associated with the response |
| Connection | Information about the connection |
Frequently encountered HTTP headers and the information they represent
Status-Driven Handling
The status line is the first part of the response because the client needs the response status before it processes the document body. The status code helps the client decide how to treat the response: as a successful result, as a response requiring redirection handling, or as an error that needs different handling. The body and headers still matter, but the status is the first signal about the outcome.
Parsing Mistakes
Treating the response as only file data
The response begins with a status line and headers before the body. The initial content is structured metadata, not necessarily the file content.
Fix:
Process the response in order: status line, headers, blank line, and body.Ignoring the blank line
The blank line is the delimiter between the header section and the actual file content.
Fix:
Explicitly recognize the blank line as the point where header parsing ends.Reading header names without their values
Headers are key-value pairs. The value is what supplies the document metadata associated with the header name.
Fix:
Preserve each header as a name paired with its corresponding value.Ignoring the status before handling the body
The status code helps the client distinguish successful, redirected, and erroneous responses.
Fix:
Read and interpret the status line before deciding how to handle the rest of the response.
Parsing Practice
Describe the order a client should use when parsing an HTTP response. Then explain what information it can learn from Content-Type, Content-Length, and Server, and identify the exact boundary that separates those headers from the body.
Hints
- Start with the first component of the response.
- Remember that headers are metadata represented as key-value pairs.
- The body does not begin immediately after the final header; look for the delimiter.
Checking a Parser's Plan
A learner proposes this parsing plan: read the body, inspect the headers, then decide what the response status meant. What should be changed?
Move status handling first: The status line appears first and gives the client the response status used for handling.
Read the headers next: Headers follow the status line and describe the document and response metadata as key-value pairs.
Use the delimiter: The blank line marks the end of the headers.
Process the body last: The actual file content begins after the blank line, so it is processed after the response structure has been recognized.
The corrected order is status line, headers, blank line, and body, with the status guiding how the client handles the response.
Key Takeaways
- An HTTP response is organized as a status line, headers, a blank-line delimiter, and a body.
- Headers are key-value pairs that describe the document and other response metadata.
- The blank line marks the exact boundary between headers and the actual file content.
- Content-Type describes the document type, Content-Length describes its length, and Server provides server information.
- The status code helps the client choose appropriate handling for a successful, redirected, or erroneous response.
Key Takeaways
- Read an HTTP response in order: status line, headers, blank line, then body.
- Interpret headers as key-value pairs describing the document and response.
- Use the blank line as the delimiter that ends header parsing.
- Use Content-Type, Content-Length, and Server to understand important response metadata.
- Check the status code before deciding how to handle the response.