Concepts / HTTP Status Codes and Error Handling

HTTP Status Codes and Error Handling

HTTP responses follow a three-part structure: status line, headers, blank line, and body.

  • Programming
Interactive lab

Try it: HTTP Request and Response

What really happens when a browser fetches a URL: DNS lookup, TCP connection, the exact HTTP/1.1 request text, how the server picks a status code (200, 301, 304, 404, 405, 500), and how a cache with max-age and ETag avoids or shortens the next request.

How it works

  1. Check the browser cache: a copy younger than its max-age is used with no request at all; an older one is revalidated with If-None-Match.
  2. Look up the host name to get an IP address (DNS), then open a TCP connection to port 80 (http) or 443 (https).
  3. Send the request line (method, path, HTTP/1.1), one header per line, a blank line, and the body if any.
  4. The server routes the path: missing → 404, wrong method → 405 with Allow, crash → 500, moved → 301 with Location, matching ETag → 304, otherwise 200 with Content-Type, Content-Length, ETag and Cache-Control.
  5. The client follows a 301 to its Location, stores a cacheable 200, or reuses its cached body after a 304.

Default run (17 steps): The browser will request GET http://data.pr4e.org/page1.htm, then visit it again 90 s later. Browser cache: on. … Done. Visit 1: 200; Visit 2: 304.

Simplified: A toy browser and one toy server on a simulated clock (fixed per-phase delays). The DNS resolver is a three-entry table, TLS is a single step with no real cryptography, every request opens a new connection (Connection: close), only 200 responses to GET are cached, and ETags are a toy hash of the body. No real network traffic is sent.

Educational simulation

Loading the simulation…

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?

  • Only the file content

  • A status line, headers, and a blank-line delimiter

  • The body first, followed by headers

  • A list of file names

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.

Status lineresponse resultHeadersdocument metadataBlank linesection delimiterBodyfile contentfollowed byends atseparates from
What contains what in an HTTP response, and how are the status line, headers, blank line, and body arranged?
ClientStatus lineHeadersBlank lineBodyreads firstthenthenthen
What does the client encounter next as it reads an HTTP response from top to bottom?

A Response Read Step by Step

Worked example

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?

  1. 1
    Find the beginning

    The first component is the status line. It gives the client the response status before the document metadata appears.

  2. 2
    Read the metadata

    The client reads the headers as key-value pairs. These pairs describe the document and other response information.

  3. 3
    Find the delimiter

    The client identifies the blank line after the headers. This is the boundary between metadata and file content.

  4. 4
    Read the body

    The content after the blank line is treated as the response body, or the actual file content.

Result

The body begins immediately after the blank line that ends the header section.

HeadersmetadataBlank lineboundaryBodyfile contentends atseparates from
How can a client tell where the headers end and the response body begins?

Header Key-Value Pairs

Definition

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.

Content-Typedocument typetype valuedescribes contentContent-Lengthdocument lengthlength valuedescribes sizeServerserver informationserver valuedescribes serverhas valuehas valuehas value
How are header names connected to their values, and how does the client interpret those pairs?
HeaderWhat it describes
Content-TypeThe type of the document or content
Content-LengthThe length of the document or content
ServerInformation about the server
DateDate information associated with the response
ConnectionInformation 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.

Read statusSuccessful resultRedirect handlingError handlingsuccessful statusredirect statuserror status
How does a status code direct the client to treat a response as successful, redirected, or erroneous?

Parsing Mistakes

  • Common mistake

    Treating the response as only file data

    What it looks like

    A parser begins processing the first received content as if it were the requested document.

    Why it fails

    The response begins with a status line and headers before the body. The initial content is structured metadata, not necessarily the file content.

    Do this instead

    Process the response in order: status line, headers, blank line, and body.

  • Common mistake

    Ignoring the blank line

    What it looks like

    A parser keeps interpreting body content as additional headers.

    Why it fails

    The blank line is the delimiter between the header section and the actual file content.

    Do this instead

    Explicitly recognize the blank line as the point where header parsing ends.

  • Common mistake

    Reading header names without their values

    What it looks like

    A parser records Content-Type but discards the information paired with it.

    Why it fails

    Headers are key-value pairs. The value is what supplies the document metadata associated with the header name.

    Do this instead

    Preserve each header as a name paired with its corresponding value.

  • Common mistake

    Ignoring the status before handling the body

    What it looks like

    A client processes every body as though every response represented the same outcome.

    Why it fails

    The status code helps the client distinguish successful, redirected, and erroneous responses.

    Do this instead

    Read and interpret the status line before deciding how to handle the rest of the response.

Parsing Practice

MEDIUM

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.
Worked example

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?

  1. 1
    Move status handling first

    The status line appears first and gives the client the response status used for handling.

  2. 2
    Read the headers next

    Headers follow the status line and describe the document and response metadata as key-value pairs.

  3. 3
    Use the delimiter

    The blank line marks the end of the headers.

  4. 4
    Process the body last

    The actual file content begins after the blank line, so it is processed after the response structure has been recognized.

Result

The corrected order is status line, headers, blank line, and body, with the status guiding how the client handles the response.

Key Takeaways

  1. 1
    An HTTP response is organized as a status line, headers, a blank-line delimiter, and a body.
  2. 2
    Headers are key-value pairs that describe the document and other response metadata.
  3. 3
    The blank line marks the exact boundary between headers and the actual file content.
  4. 4
    Content-Type describes the document type, Content-Length describes its length, and Server provides server information.
  5. 5
    The status code helps the client choose appropriate handling for a successful, redirected, or erroneous response.

At a glance

  • 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.

Related Topics

Related concepts

More concepts starting with H