HTTP
A web page is usually assembled from many pieces: HTML, CSS, JavaScript, images, fonts, and later API calls. HTTP is the protocol that lets a client ask for those resources and lets a server answer.
Most browser HTTP traffic follows a client-server pattern. The browser or another user agent starts the exchange. The server handles the request and sends back a response.
The Basic Exchange
A request says what the client wants:
| Request part | Purpose |
|---|---|
| Method | The kind of operation, such as GET, POST, HEAD, or OPTIONS. |
| Path | The resource being requested on the server. |
| Headers | Metadata such as accepted formats, host, cookies, or authorization data. |
| Body | Optional data sent by the client, common with form submissions and APIs. |
A response says what happened:
| Response part | Purpose |
|---|---|
| Status code | Machine-readable result, such as success, redirect, client error, or server error. |
| Status text | Short human-readable label for the status. |
| Headers | Metadata such as content type, cache policy, cookies, or CORS policy. |
| Body | Optional returned resource, such as HTML, JSON, an image, or an error document. |
Stateless, Not Useless
HTTP itself does not remember that two requests belong to the same user journey. Each request must carry enough information for the server to understand it.
Web applications build sessions on top of that stateless core. Cookies are the common mechanism: the server asks the browser to store a small value, and the browser sends it back on later matching requests.
This is why a shopping cart, login session, or personalized setting can exist even though the protocol's basic message model does not keep conversation state by itself.
Connections and Latency
HTTP messages travel over lower network layers. In common deployments, that means a transport connection must exist before requests and responses can move.
Older HTTP behavior often paid connection setup costs repeatedly. Later versions made connection reuse and multiplexing more important, because many small resources can otherwise turn into many visible round trips. This is one concrete example of latency-aware remote calls: the message shape and connection behavior affect user-visible performance.
Intermediaries
A browser and server are often not the only machines involved. Proxies, gateways, caches, load balancers, and authentication layers may sit between them.
Some intermediaries are almost invisible at the HTTP layer. Others intentionally change behavior: caching a response, filtering a request, routing traffic to one of many servers, recording logs, or enforcing access rules.
What HTTP Can Control
HTTP's headers make the protocol extensible. Over time, headers have become the control surface for many Web behaviors:
- caching rules;
- authentication challenges and credentials;
- cookies and sessions;
- proxy behavior;
- cross-origin access through Cross-Origin Resource Sharing.
The durable idea is not that every feature belongs inside HTTP forever. It is that the request-response envelope gives clients, servers, and intermediaries a shared place to describe what they are doing.