← All posts

Reading fromTech Explained Simply

Volume 1 · Chapter 5
6 min read

HTTP Requests and Responses: The Structured Conversation of the Web

#technology#computer-science#http#web
📑 On this page

When a browser loads a page, it does not ask the server in an informal sentence. It sends a structured HTTP request. The server returns a structured HTTP response.

HTTP is an application-layer protocol defining messages for requesting resources or actions and returning status, metadata, and content.

HTTP describes the conversation. DNS, TCP or QUIC, TLS, IP, and link technologies carry it.

Request structure

An HTTP request conceptually contains:

  • Method
  • Target
  • Version
  • Headers
  • Optional body

A simplified request:

GET /news?page=2 HTTP/1.1
Host: example.com
Accept: text/html
User-Agent: ExampleBrowser/1.0

The method expresses intent. The target identifies the resource within the server. Headers carry metadata.

HTTP/2 and HTTP/3 encode messages differently on the wire, but preserve equivalent concepts.

Methods

Common methods include:

GET

Retrieve a representation.

POST

Submit data or request processing, often creating an action or resource.

PUT

Replace or create a resource at a known target.

PATCH

Apply a partial modification.

DELETE

Request resource removal.

Retrieve response headers without the response body.

The protocol defines semantics, but applications can misuse methods. A GET request should be safe and not intentionally change server state.

Request headers

Headers can communicate:

  • Accepted content types
  • Compression support
  • Authentication
  • Cookies
  • Cache validators
  • Origin information
  • Preferred language
  • Body type and length

Example:

Accept-Encoding: gzip, br
Authorization: Bearer ...
Content-Type: application/json

Headers are not inherently trusted. Servers validate every security-sensitive value.

Request body

Requests such as POST and PUT commonly include a body.

Possible formats:

  • JSON
  • Form data
  • File upload
  • XML
  • Binary protocol

Content-Type tells the receiver how the sender represents the body.

If the header says JSON but the bytes are invalid JSON, the server should reject or handle the mismatch rather than guessing blindly.

Response structure

An HTTP response contains:

  • Status code
  • Reason category
  • Headers
  • Optional body

Simplified:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: br
Cache-Control: max-age=300
 
<!doctype html>...

The status describes the request outcome. Headers describe representation and policy. The body carries content.

Status-code families

1xx: informational

Interim communication.

2xx: success

Examples:

  • 200 OK
  • 201 Created
  • 204 No Content

3xx: redirection

Examples:

  • 301 Moved Permanently
  • 302 Found
  • 304 Not Modified

4xx: client-side request problem

Examples:

  • 400 Bad Request
  • 401 Unauthorized
  • 403 Forbidden
  • 404 Not Found
  • 429 Too Many Requests

5xx: server-side failure

Examples:

  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

A 404 means the server did not provide the requested resource in that context; it does not prove the entire server is offline.

A concrete page load

For https://example.com/news:

  1. DNS resolves the host.
  2. The browser establishes a secure connection.
  3. It sends GET /news.
  4. The server authenticates or routes the request.
  5. Application code reads data and creates HTML.
  6. The response returns status 200 and headers.
  7. The browser parses the HTML.
  8. It sends additional requests for CSS, JavaScript, images, and data.

One visible page can involve dozens or hundreds of HTTP exchanges.

Content negotiation

A resource can have several representations.

Clients can advertise preferences:

Accept: application/json
Accept-Language: en
Accept-Encoding: br, gzip

The server selects a representation and describes it in response headers.

CDNs and caches must account for headers that influence content, often using Vary.

Incorrect caching across language or encoding variants can serve the wrong content.

HTTP caching

Responses can specify caching policy:

Cache-Control: max-age=3600

Validators such as ETag or Last-Modified allow conditional requests:

If-None-Match: "abc123"

If unchanged, the server returns:

304 Not Modified

without a full body.

Caching reduces latency, server work, and bandwidth. Sensitive or personalized responses require careful policy.

Connections and HTTP versions

HTTP/1.1 can reuse connections but requests have ordering limitations.

HTTP/2 multiplexes several streams over one connection and compresses headers.

HTTP/3 runs over QUIC, usually using UDP, and improves behavior under some loss and network-change conditions.

The request-response semantics remain familiar while transport details evolve.

Applications should not assume one request equals one TCP connection.

Idempotency

An operation is idempotent when repeating the same request has the same intended effect as performing it once.

GET, PUT, and DELETE are defined with idempotent semantics, although responses can differ.

POST is not generally idempotent.

Retries after uncertain failures should use:

  • Idempotent methods
  • Idempotency keys
  • Duplicate detection
  • Transactional design

Otherwise a timeout after a successful payment can cause the client to submit the charge again.

Authentication and cookies

HTTP can carry credentials through:

  • Authorization headers
  • Cookies
  • Client certificates

HTTPS is needed to protect secrets in transit.

Authentication identifies or verifies a principal. Authorization determines whether that principal may perform the requested action.

The server must enforce permissions for every protected request, not rely only on hiding buttons in the browser.

Common misunderstandings

"HTTP is the same as the internet"

HTTP is one application protocol carried over lower networking layers.

"POST is automatically more secure than GET"

Security comes from HTTPS and correct application handling. POST bodies are not encrypted without TLS.

"A 200 response means the content is correct"

It means the server reports successful handling. The body can still contain application errors or malicious content.

"One page equals one HTTP request"

Pages usually request many dependent resources and APIs.

Knowledge check

1. What are the main parts of an HTTP request?

Method, target, headers, and an optional body.

2. What does 304 Not Modified mean?

The client's cached representation remains valid, so the server does not send the full body again.

3. Why does idempotency matter for retries?

It prevents repeated delivery from unintentionally repeating the operation's effect.

4. Does a POST body have encryption by default?

No. HTTPS/TLS protects both headers and bodies during transit.

The one idea to remember

HTTP is a structured application conversation: clients send methods, targets, headers, and sometimes bodies; servers return status, headers, and content.

Caching, negotiation, authentication, retries, and evolving HTTP versions build on that basic exchange.

Next, we will examine how HTTPS uses TLS to protect those messages while they travel.