HTTP Request

An HTTP request is the message a client sends to a server to initiate an action on a resource. Every interaction on the web starts with a request: loading a page, submitting a form, calling an API, downloading a file. The request specifies what action to perform (the method), which resource to act on (the request target), and metadata describing the client and its preferences (the Headers).

Usage

HTTP follows a request-response model. The client sends a HTTP request, the server processes the HTTP request, and the server returns a Response. Each HTTP request is self-contained. The server does not retain memory of previous HTTP requests from the same client. Cookies and tokens maintain state across HTTP requests when needed.

Browsers, API clients, mobile apps, IoT devices, and search engine crawlers all send HTTP requests. A browser loading a single web page sends dozens of HTTP requests: one for the HTML document, then additional HTTP requests for stylesheets, scripts, images, and fonts referenced in the HTML.

Request structure

An HTTP request message has three parts:

Request line: the method, request target, and HTTP version
HTTP headers: zero or more name-value pairs carrying metadata
Body: optional content containing data for the server to process

A blank line (CRLF) separates the headers from the body. In HTTP/1.1, the HTTP request line and HTTP headers are plain text. In HTTP/2 and HTTP/3, the same information is encoded as binary frames.

Request line

The HTTP request line contains three elements separated by spaces:

GET /api/products?page=2 HTTP/1.1

Method (GET): the action to perform
Request target (/api/products?page=2): the resource path and query string
HTTP version (HTTP/1.1): the message syntax version

The method is case-sensitive. The request target contains no whitespace. Servers are recommended to support request lines of at least 8000 bytes. Servers return 414 when the request target exceeds their capacity.

Request target forms

The request target takes one of four forms depending on the method and the type of request:

Origin-form: the path and optional query string. Used for most requests to origin servers. When the path is empty, the client sends /.

GET /about HTTP/1.1
POST /api/users?notify=true HTTP/1.1

Absolute-form: the complete URL including scheme and authority. Used for HTTP requests through forward proxies.

GET http://www.example.re/page HTTP/1.1

Authority-form: the host and port. Used exclusively with the CONNECT method for establishing tunnels.

CONNECT www.example.re:443 HTTP/1.1

Asterisk-form: a single *. Used with OPTIONS to query server-wide capabilities rather than a specific resource.

OPTIONS * HTTP/1.1

Methods

The method in the request line tells the server what action to perform. Nine standard methods are defined.

Method	Purpose	Body
GET	Retrieve a resource	No
HEAD	Retrieve headers only	No
POST	Submit data for processing	Yes
PUT	Replace a resource	Yes
DELETE	Remove a resource	Optional
PATCH	Partially modify a resource	Yes
OPTIONS	Query server capabilities	Optional
CONNECT	Establish a tunnel	No
TRACE	Loop-back diagnostic test	No

The QUERY method (in development) combines the safety of GET with the ability to include a request body for complex queries exceeding practical URL length limits.

Methods are classified by two properties. Safe methods (GET, HEAD, OPTIONS, TRACE) do not modify server state. Idempotent methods (all safe methods plus PUT and DELETE) produce the same server state regardless of how many times the HTTP request is repeated.

Request headers

HTTP Headers carry metadata about the HTTP request, the client, and the desired response. The Host header is the only header required in HTTP/1.1.

Host

Host: www.example.re

The Host header identifies the target server by hostname and optional port. Servers hosting multiple domains on a single IP address use this header to route the request to the correct virtual host. Servers return 400 when a request lacks a valid Host header.

In HTTP/2 and HTTP/3, the :authority pseudo-header replaces Host.

Content negotiation

These headers communicate the client's preferences for the response format:

Accept: text/html, application/json;q=0.9
Accept-Encoding: gzip, br, zstd
Accept-Language: en-US, de;q=0.7

Accept lists preferred media types. Accept-Encoding lists preferred Compression algorithms. Accept-Language lists preferred languages. Quality values (q=0.0 to q=1.0) rank preferences, where higher values indicate stronger preference.

Authentication

Authorization: Bearer eyJhbGciOiJIUz...
Cookie: session=abc123; theme=dark

The Authorization header carries credentials (tokens, API keys, or encoded username-password pairs). The Cookie header sends stored Cookies back to the server for Session management.

Conditional headers

If-None-Match: "etag-v7"
If-Modified-Since: Mon, 03 Mar 2026 10:00:00 GMT

Conditional headers make the request outcome dependent on the current state of the resource. If-None-Match compares ETags. If-Modified-Since compares timestamps. When the condition fails, the server returns 304 instead of transferring the full resource, saving bandwidth and reducing latency.

Client identification

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
Referer: https://www.example.re/search?q=http

The User-Agent header identifies the client software. The Referer header indicates the URL of the page the request originated from.

Cache directives

Cache-Control: no-cache

The Cache-Control header in requests controls how caches handle the request. no-cache requires validation with the origin server before serving a cached Response. no-store prevents Caching entirely. max-age=0 treats cached responses as stale.

Request body

The request body carries data for the server to process. Methods like POST, PUT, PATCH, and QUERY expect a body. GET and HEAD requests typically have no body.

The Content-Type header declares the format of the body. The Content-Length header declares the size in bytes.

JSON body

An API request creating a new resource:

POST /api/users HTTP/1.1
Host: api.example.re
Content-Type: application/json
Content-Length: 52
Authorization: Bearer eyJhbGciOiJIUz...

{"name":"Jane Doe","email":"jane@example.re"}

Form submission

A browser submitting an HTML form:

POST /login HTTP/1.1
Host: www.example.re
Content-Type: application/x-www-form-urlencoded
Content-Length: 29

username=jane&password=secret

Form data uses URL-encoded key-value pairs separated by &.

File upload

A multipart form uploading a file:

POST /upload HTTP/1.1
Host: www.example.re
Content-Type: multipart/form-data; boundary=----FormBoundary
Content-Length: 348

------FormBoundary
Content-Disposition: form-data; name="title"

Report Q1
------FormBoundary
Content-Disposition: form-data; name="file"; filename="report.pdf"
Content-Type: application/pdf

(binary PDF data)
------FormBoundary--

Each part has its own Content-Disposition and optional Content-Type headers. The boundary string separates parts.

Requests across HTTP versions

HTTP/1.1

HTTP/1.1 sends requests as plain text. The request line, headers, and blank line are ASCII characters terminated by CRLF. Persistent connections are the default. A single TCP connection carries multiple request-response exchanges. Chunked transfer encoding allows sending a body of unknown length.

GET /page HTTP/1.1
Host: www.example.re
Accept: text/html

HTTP/2

HTTP/2 encodes the same information as binary frames. There is no text-based request line. Instead, pseudo-header fields carry the control data:

:method: the HTTP method
:scheme: the URL scheme (http or https)
:authority: the host (replaces the Host header)
:path: the path and query string

Multiple requests flow concurrently over a single TCP connection through multiplexed streams. HPACK compression reduces header overhead from repetitive headers across requests.

HTTP/3

HTTP/3 uses the same pseudo-header fields as HTTP/2 but runs over QUIC instead of TCP. Each request occupies its own QUIC stream, eliminating head-of-line blocking. A stalled request does not block other requests on the same connection. QPACK replaces HPACK for header compression, designed for QUIC's stream independence.

Common request patterns

A browser navigating to a web page sends a GET request for the HTML document, followed by additional requests for linked resources:

GET /about HTTP/1.1
Host: www.example.re
Accept: text/html
Accept-Encoding: gzip, br, zstd
Accept-Language: en-US
Cookie: session=abc123
User-Agent: Mozilla/5.0 ...

API call

A REST API call fetching data with Authentication:

GET /api/products?category=books HTTP/1.1
Host: api.example.re
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUz...

Cache validation

A conditional request checking whether a cached resource has changed:

GET /styles.css HTTP/1.1
Host: www.example.re
If-None-Match: "css-v42"
If-Modified-Since: Sun, 02 Mar 2026 08:00:00 GMT

The server returns 304 Not Modified with no body when the resource has not changed, or 200 with the full resource when the content is different.

CORS preflight

Browsers automatically send an OPTIONS request before cross-origin requests using non-simple methods or headers:

OPTIONS /api/data HTTP/1.1
Host: api.example.re
Origin: https://www.example.re
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: Authorization

The server responds with Access-Control-Allow-Origin and related CORS headers indicating whether the cross-origin request is permitted.

Security

Plain HTTP sends requests in cleartext. Any device on the network path reads the full request including URLs, Headers, and body content. HTTPS encrypts the entire request over TLS.

The Authorization and Cookie headers carry sensitive credentials and are only safe over HTTPS. The Referer header exposes the referring URL, which sometimes contains session tokens or personal data in query strings. The Referrer-Policy response header controls how much referrer information is sent with subsequent requests.

SEO impact

Search engine crawlers like Googlebot are HTTP clients sending standard requests. Googlebot sends GET requests with its own User-Agent string and follows the same HTTP protocol rules as browsers. Server behavior depending on User-Agent sniffing instead of proper content negotiation risks serving different content to crawlers than to regular visitors.

Takeaway

An HTTP request initiates every interaction on the web. The request line specifies the method and target resource. HTTP Headers carry metadata (client preferences, credentials, cache directives, and conditions). The optional body carries data for methods like POST and PUT. From HTTP/1.1's plain text format to HTTP/3's binary frames over QUIC, the request structure remains the same: method, target, headers, and body.