Backend

HTTP Explained: How the Web Actually Communicates

Code to Ship
2026-02-02
10 min read

When you open a website, submit a form, or load data in an app, HTTP is quietly doing the heavy lifting.

Most people learn HTTP as a list of methods, status codes, and headers. That’s useful. But it doesn’t explain why HTTP works the way it does, or how all these pieces fit together in real systems.

What Is HTTP?

HTTP (Hypertext Transfer Protocol) is the communication medium between a client and a server.

  • The client is usually a browser, mobile app, another server
  • The server hosts resources and responds to requests

HTTP defines:

  • How requests are sent
  • How responses are returned
  • How both sides understand each other

At its core:

Client -> HTTP -> Server

HTTP Is Stateless (And That’s a Feature)

HTTP is stateless.

That means:

  • The server does not remember previous requests
  • Every request is treated as brand new

Each HTTP request must carry all the information the server needs:

  • Header
  • URL
  • Method
  • Authentication data (cookies, tokens, etc.)

Example:

If a user requests their profile:

  • The browser must send authentication info every time
  • The server does not remember who the user was previously

This might sound inefficient, but it brings big advantages.

Benefits of Statelessness:

  1. Simplicity - servers don’t maintain client memory
  2. Scalability - any server can handle any request

State (sessions, cookies, tokens) is managed by developers, not by HTTP itself.

The Client - Server Model

HTTP follows a client-server model.

  • The client always initiates communication
  • The server only responds

The client provides:

  • The resource URL
  • Headers
  • Method

The server:

  • Hosts resources
  • Processes requests
  • Returns responses

Servers never call clients first.

HTTP and the Network (Just Enough Context)

HTTP sits at the application layer.

Under the hood:

  • HTTP traditionally uses TCP for reliable delivery
  • It doesn’t care how reliability is achieved, only the messages arrive correctly

As backend engineer, we mostly operate at the application layer, with only light awareness of transport details.

HTTP vs HTTPS

HTTPS is simply HTTP with security.

It adds:

  • Encryption
  • Certificates
  • Secure communication using TLS

Modern browsers treat HTTPS as default.

HTTP Versions (Why They Exist)

HTTP/1.0

  • A new connection for every request
  • Very inefficient

HTTP/1.1

  • Introduced persistent connections
  • Still inefficient in some ways

HTTP/2

  • Added multiplexing
  • Multiple requests and responses in parallel over one connection
  • Responses can arrive out of order

HTTP/3

  • Runs over UDP instead of TCP
  • Handles packet loss better
  • Faster performance under real world network conditions

HTTP Messages: Requests and Responses

Request Format

METHOD /resource HTTP/version
Host: example
Headers ...

Body (optional)

The blank line separates headers from the body.

Response Format

HTTP/version Status-Code Status-Text
Headers ...

Body

HTTP Headers (Metadata That Makes Everything Work)

Headers are key-valued pairs that describe the request or response.

Why not put everything in the body or URL?

Think of shipping a package:

  • Address and instructions go outside the box
  • The content stays inside

Headers are metadata. Information needed to correctly handle the message.

Types of HTTP Headers

1. Request Headers Sent by the client to describe the request

  • User-Agent: who is making the request
  • Authorization: credentials (tokens, cookies)
  • Accept: expected response format

2. General Headers Used in both requests and responses

  • Date
  • Cache-Control
  • Connection

3. Representation Headers Describe the body itself:

  • Content-Type
  • Content-Length
  • Content-Encoding
  • ETag

These ensures the message is interpreted correctly.

4. Security Headers Used to enforce browser security

  • Strict-Transport-Security
  • Content-Security-Policy
  • X-Frame-Options
  • X-Content-Type-Options

Set-Cookie flags like Secure and HttpOnly protect cookies from misuse.

Two Big Ideas Behind Headers

1. Extensibility HTTP is extremely flexible. You can:

  • Add new headers
  • Create custom headers
  • Change behaviour without changing the protocol

This is why HTTP has survived decades of evolution.

2. Remote Control Headers let clients influence server behaviour:

  • Content negotiation
  • Caching rules
  • Authentication

They act like a remote control for request lifecycle.

HTTP Methods (Intent Matters)

Methods describe what the client wants to do.

  • GET: read data
  • POST: create data
  • PATCH: update part of resource
  • PUT: replace a resource entirely
  • DELETE: remove a resource

PATCH vs PUT

  • PATCH -> partial update
  • PUT -> full replacement

In practice: use PATCH unless full replacement is required.

Idempotent vs Non-Idempotent Methods

  • Idempotent: calling multiple times gives the same result (GET, PUT, DELETE)
  • Non-idempotent: repeated calls create new effects (POST)

OPTIONS and CORS in detail

Browsers enforce the Same-Origin Policy by default.

This means a web page can only make requests to:

  • The same scheme (http/https)
  • The same domain
  • The same port

If any of these differ, the browser blocks the response unless CORS rules explicitly allow it.

CORS (Cross-Origin Resource Sharing) is not a server-to-server rule. It is a browser security mechanism. Servers do not block requests. Browsers do.

What Actually Triggers CORS?

A request becomes a cross-origin request when:

  • Frontend: https://shop.example.com
  • Backend: https://api.shop.example.com

Even though both belong to the same project, they are different origins.

Simple Requests

A request is considered simple if all of the following are true:

  • Method is GET, POST or HEAD
  • Headers are only simple headers
  • Content-Type is one of: application/x-www-form-urlencoded, multipart/form-data, text/plain

Example:

GET /products
Origin: https://shop.example.com

Server response:

Access-Control-Allow-Origin: https://shop.example.com

If the header matches the request origin, the browser allows access.

Preflight Requests (OPTIONS)

A preflight request happens when:

  • Method is PUT, PATCH or DELETE
  • Custom headers are used (e.g Authorization)
  • Content-Type is application/json

Before the real request, the browser sends:

OPTIONS /products/123
Origin: https://shop.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Authorization, Content-Type

The server must respond with:

Access-Control-Allow-Origin: https://shop.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 600

Only after this succeeds will the browser send the actual request.

Important CORS Rules

  • CORS errors are browser-side, not server-side
  • Server still processes the request
  • Browser blocks Javascript access to the response
  • Tools like curl bypass CORS entirely

HTTP Status Codes (A Universal Language)

Status codes communicate results without reading the body.

Categories

  • 1xx - Informational
  • 2xx - Success
  • 3xx - Redirection
  • 4xx - Client errors
  • 5xx - Server errors

Common Status Codes

  • 200 OK
  • 201 Created
  • 204 No Content
  • 301 Permanent Redirect
  • 302 Temporary Redirect
  • 304 Not Modified
  • 400 Bad Request
  • 401 Unauthorized
  • 403 Forbidden
  • 404 Not Found
  • 409 Conflict
  • 429 Too Many Requests
  • 500 Internal Server Error
  • 502 Bad Gateway
  • 503 Service Unavailable
  • 504 Gateway Timeout

Caching

Caching avoids unnecessary requests.

Server sends:

  • Cache-Control
  • ETag
  • Last-Modified

Client reuses cached data when possible. If unchanged, server replies: 304 Not Modified No body. No bandwidth issue.

Content Negotiation

Client and servers agree on:

  • Media type (Accept)
  • Language (Accept-Language)
  • Encoding (Accept-Encoding)

This allows flexible responses without changing URLs.

Compression

Large responses are compressed (gzip, deflate).

  • Saves bandwidth
  • Improved performance

Browser automatically decompresses responses.

Handling Large Requests and Responses

Multipart Requests Used for file uploads. Data is sent in parts, separated by boundaries.

Streaming Responses Servers can stream data in chunks:

  • Content-Type: text/event-stream
  • Connection: keep-alive

Client receives data incrementally.

Persistent Connections and Keep-Alive

HTTP/1.1 keeps connections open by default. This avoids repeatedly opening and closing TCP connections. Headers like Connection: keep-alive fine-tune behaviour.

SSL, TLS and HTTPS

  • SSL was the original encryption protocol
  • TLS replaced SSL due to security issues
  • TLS 1.3 is the current standard

HTTPS = HTTP + TLS

It encrypts data and authenticates servers using certificates.

Final Thoughts

HTTP isn’t complicated. It’s layered.

Once you understand:

  • Stateless
  • Headers
  • Methods
  • Status codes

Everything else becomes predictable. This understanding makes debugging, designing APIs, and building and shipping large scale solutions much easier.