What Is HTTP and How Does It Work?

The Request-Response Model

HTTP (Hypertext Transfer Protocol) follows a simple pattern: the client sends a request, the server sends a response. Every interaction is one request matched to one response. The client (usually a browser) initiates the conversation. The server never contacts the client unsolicited.

A request contains a method (what action to perform), a URL (which resource to act on), headers (metadata about the request), and optionally a body (data to send to the server). A response contains a status code (what happened), headers (metadata about the response), and a body (the requested content).

HTTP runs over TCP, typically on port 80 (or 443 for HTTPS). The TCP connection handles reliable delivery; HTTP focuses on the semantics of the request and response.

HTTP Methods

HTTP defines several methods (also called verbs) that specify the intended action:

• GET - retrieve a resource. The most common method. Loading a web page is a GET request. GET requests should not modify anything on the server.
• POST - submit data to the server. Used for form submissions, file uploads, and API calls that create or modify resources. The data is in the request body.
• PUT - replace a resource entirely with the data in the request body. Used in APIs to update an existing resource.
• DELETE - remove a resource. Used in APIs to delete a specified resource.
• PATCH - partially modify a resource. Unlike PUT, which replaces the entire resource, PATCH sends only the fields that should change.
• HEAD - identical to GET but returns only the headers, not the body. Used to check if a resource exists or to read its metadata without downloading the full content.
• OPTIONS - asks the server which methods and headers it supports for a given resource. Used by browsers in CORS (Cross-Origin Resource Sharing) preflight requests.

In practice, most web traffic is GET (loading pages and resources) and POST (submitting forms and API calls). PUT, DELETE, and PATCH appear primarily in REST APIs.

sequenceDiagram
    participant Browser
    participant Server
    Browser->>Server: GET /index.html HTTP/1.1
    Note over Browser: Method + URL + Version
    Server->>Browser: HTTP/1.1 200 OK
    Note over Server: Status + Headers + Body
    Browser->>Server: POST /login (username, password)
    Server->>Browser: HTTP/1.1 302 Found (redirect)
    Browser->>Server: GET /dashboard
    Server->>Browser: HTTP/1.1 200 OK

Status Codes

Every HTTP response includes a three-digit status code that tells the client what happened:

1xx - Informational: the request was received and processing continues. Rarely seen in normal browsing.

2xx - Success: the request succeeded.

• 200 OK - the standard success response
• 201 Created - a new resource was created (typical response to POST)
• 204 No Content - success, but no body to return

3xx - Redirection: the client must take additional action.

• 301 Moved Permanently - the resource has a new URL permanently
• 302 Found - temporary redirect
• 304 Not Modified - the cached version is still valid

4xx - Client Error: the request was invalid.

• 400 Bad Request - malformed request syntax
• 401 Unauthorized - authentication required
• 403 Forbidden - authenticated but not authorized for this resource
• 404 Not Found - the resource does not exist
• 429 Too Many Requests - rate limiting

5xx - Server Error: the server failed to process a valid request.

• 500 Internal Server Error - generic server failure
• 502 Bad Gateway - the server got an invalid response from an upstream server
• 503 Service Unavailable - the server is overloaded or down for maintenance

Headers

HTTP headers carry metadata about the request or response. They are key-value pairs sent before the body. Important headers include:

• Host - the domain name the client is requesting (required in HTTP/1.1, enables virtual hosting)
• Content-Type - the format of the body (text/html, application/json, multipart/form-data)
• Content-Length - the size of the body in bytes
• User-Agent - identifies the client software (browser name and version)
• Cookie - sends stored cookies back to the server
• Set-Cookie - the server tells the client to store a cookie
• Authorization - carries authentication credentials (tokens, API keys)
• Cache-Control - directs caching behavior

Headers are transmitted in plaintext in HTTP (not HTTPS). This means anyone monitoring the network can read them, including cookies and authorization tokens. This is one of the primary reasons HTTPS exists.

HTTP Is Stateless

Each HTTP request is independent. The server does not remember previous requests from the same client. If you load a page and then click a link, the server treats the second request as a completely new interaction with no memory of the first.

This is a deliberate design choice that makes HTTP simple and scalable. Any server in a cluster can handle any request without needing to know the client's history. But it creates a problem: how do you stay logged in? How does a shopping cart persist across page loads?

The answer is cookies. The server sends a Set-Cookie header with a session identifier. The browser stores the cookie and sends it back with every subsequent request to that domain. The server uses the session ID to look up the client's state in a server-side session store. The protocol is stateless, but the application builds state on top of it using cookies.

HTTP Versions

HTTP/1.0 (1996) - one request per TCP connection. The client opens a connection, sends one request, gets one response, and the connection closes. Loading a page with 50 resources required 50 separate TCP connections.

HTTP/1.1 (1997) - persistent connections (keep-alive) allow multiple requests over a single TCP connection. Pipelining allows sending multiple requests without waiting for responses, though head-of-line blocking limits its effectiveness. Still the most widely deployed version.

HTTP/2 (2015) - binary protocol with multiplexing. Multiple requests and responses can be interleaved on a single TCP connection without head-of-line blocking. Header compression (HPACK) reduces overhead. Server push allows the server to send resources before the client requests them.

HTTP/3 (2022) - runs over QUIC (which runs over UDP) instead of TCP. Eliminates TCP's head-of-line blocking at the transport layer. Faster connection establishment (0-RTT in some cases). Built-in encryption (QUIC always uses TLS 1.3).

Security Implications

Plain HTTP transmits everything in cleartext. Request URLs, headers (including cookies and auth tokens), and response bodies are all readable by anyone who can capture the traffic. On WiFi, this means anyone within radio range.

The BLEShark Nano's captive portal serves HTTP to connected clients. When a device connects to the Nano's rogue AP and opens a browser, the HTTP exchange is how the portal page reaches the client. The client's browser sends an HTTP GET request, the Nano's web server responds with the portal HTML, and any form submissions from the client are HTTP POST requests that the Nano captures.

This is also why captive portals present a security paradox: the portal itself runs over unencrypted HTTP on a network the client has no reason to trust. Modern browsers increasingly warn users about HTTP connections, especially when forms are present. Understanding HTTP's security model - or lack thereof - is fundamental to both attacking and defending web-based systems.

Get the BLEShark Nano