Hypertext Transfer Protocol (HTTP)

The Hypertext Transfer Protocol (HTTP) is the dominant application-layer protocol of the web: a stateless request/response protocol in which a client sends a request message and the server returns a response message. HTTP/1.1 semantics are defined by RFC 9110 (HTTP Semantics)¹, with the HTTP/1.1 message syntax and framing in RFC 9112²; these 2022 revisions obsolete RFC 7230–7235.

A minimal HTTP request

GET / HTTP/1.1
host: something
 

Note the terminating blank line — an empty line (CRLF) separates the header section from the body. Host is the only header field a client must send in HTTP/1.1 requests (RFC 9110 §7.2)³; field names are case-insensitive (RFC 9110 §5.1)⁴.

Message anatomy

• Request line — method, request-target, HTTP version
• Header fields — key/value metadata, terminated by an empty line
• Content (body) — optional; present mostly on POST/PUT/PATCH requests

Security-relevant headers

HTTP headers are relatively arbitrary — a proxy must forward unrecognized fields (RFC 9110 §5.1)⁵. Common ones to watch in assessments:

• Server — web server information (Apache, nginx, etc.); useful for recon.
• X-Powered-By — added by some application engines to advertise themselves; recon value.
• True-Client-IP — may override the client IP for direct connections.
• X-Forwarded-For — client-IP override for proxied connections; trusted by many apps and a classic spoofing/logging vector.
• Content-Type — describes the body; normally set by the client only on requests with bodies (e.g. form data uses application/x-www-form-urlencoded).
• Content-Length⁶ — body length in bytes; the framing signal that request smuggling desynchronizes.
• Transfer-Encoding: chunked — the HTTP/1.1 framing alternative whose disagreement with Content-Length enables CL.TE/TE.CL desyncs (RFC 9112 §6.3)⁷.

Non-standard headers were conventionally X- prefixed, but nothing enforces this — RFC 6648 actually deprecated the convention.

Framing and smuggling

HTTP/1.1 has two ways to delimit a request body: Content-Length and Transfer-Encoding: chunked. When a front-end and back-end disagree on which one applies, an attacker can smuggle a second request inside the first — see http-request-smuggling. RFC 9112 forbids sending both together, but real-world parsers are inconsistent, which is exactly the flaw the attacks exploit.

See also

• uniform-resource-locators — the request-target syntax
• http-request-smuggling — desync attacks on HTTP/1.1 framing
• http-header-command-injection — command-injection payloads hidden in request headers
• insecure-password-reset-tokens — Host-header poisoning of reset links is a classic HTTP trust flaw
• burp-suite-firefox, burp-suite-mobile-apps — intercepting HTTP traffic with Burp
• owasp-zap — open-source intercepting proxy

Sources

• RFC 9110 — HTTP Semantics
• RFC 9112 — HTTP/1.1
• MDN — Content-Length header
• MDN — HTTP resources and specifications

Footnotes

1. RFC 9110 — HTTP Semantics ↩

2. RFC 9112 — HTTP/1.1 ↩

3. RFC 9110 — HTTP Semantics ↩

4. RFC 9110 — HTTP Semantics ↩

5. RFC 9110 — HTTP Semantics ↩

6. MDN — Content-Length header ↩

7. RFC 9112 — HTTP/1.1 ↩