Glossary
Understanding HTTP
Headers

Headers

Headers are the primary extension mechanism in HTTP. They carry metadata about the message, the resource, the connection, and the client/server.

Structure 

field-name ":" OWS field-value OWS CRLF
  • field-name is case-insensitive and MUST NOT contain whitespace or colons. It must be a valid token — one or more characters from !#$%&'*+-.^_|~, digits, and letters.
  • OWS (optional whitespace) may appear between the colon and the value, and after the value.
  • No space before the colon — RFC 9112 §5.1 forbids whitespace between the field-name and the colon. Servers that receive it MUST reject the message with 400 or strip the whitespace before processing.
  • Header field values can span multiple lines using obs-fold (obsolete line folding — a CRLF followed by at least one space or tab), but this is deprecated. Servers MUST either reject obs-fold with 400 or replace it with a single space before processing.

Header Categories

HTTP headers fall into several categories based on their scope:

CategoryDescriptionExamples
Request headersSent by the client to provide context about the request.Host, Accept, Authorization, User-Agent
Response headersSent by the server to provide context about the response.Server, Set-Cookie, WWW-Authenticate
Representation headersDescribe the body content in either direction.Content-Type, Content-Length, Content-Encoding
Hop-by-hop headersConsumed by the next intermediary, not forwarded. Listed in the Connection header.Connection, Transfer-Encoding, Keep-Alive, Upgrade
End-to-end headersForwarded by intermediaries to the final recipient.Everything not listed in Connection.

Common Request Headers

HeaderPurpose
HostRequired in HTTP/1.1. Identifies the target host and port. Enables virtual hosting.
Content-TypeMedia type of the request body (e.g., application/json, multipart/form-data).
Content-LengthSize of the request body in bytes. Must be an exact decimal integer.
Transfer-EncodingBody encoding (e.g., chunked). Mutually exclusive with Content-Length in practice.
AcceptMedia types the client can handle (e.g., text/html, application/json).
Accept-EncodingCompression algorithms the client supports (e.g., gzip, deflate, br).
Accept-LanguagePreferred natural languages (e.g., en-US, pt;q=0.8).
AuthorizationCredentials for authenticating the client (e.g., Bearer <token>, Basic <base64>).
User-AgentIdentifies the client software and version.
ConnectionControls connection persistence (keep-alive, close) and lists hop-by-hop headers.
CookieSends stored cookies to the server.
If-None-MatchConditional request — send the resource only if the ETag doesn’t match (for caching).
If-Modified-SinceConditional request — send the resource only if modified after this timestamp.
ExpectIndicates expectations the server must meet (e.g., 100-continue).
RefererURL of the page that linked to the current request.

Common Response Headers

HeaderPurpose
Content-TypeMedia type of the response body (e.g., text/html; charset=utf-8).
Content-LengthSize of the response body in bytes.
Transfer-EncodingBody encoding applied to the response (e.g., chunked).
Cache-ControlCaching directives (e.g., no-cache, max-age=3600, private).
ETagOpaque identifier for a specific version of the resource. Used for conditional requests.
Last-ModifiedTimestamp of last modification. Used with If-Modified-Since.
Set-CookieSends a cookie to the client for storage.
LocationURL to redirect to (used with 3xx and 201 status codes).
ServerIdentifies the server software.
WWW-AuthenticateDefines the authentication scheme for 401 responses.
VaryLists request headers that affect the response (important for caching).
AllowLists permitted methods for the resource (required with 405 responses).
Retry-AfterSuggests how long the client should wait before retrying (used with 429/503).

The Host Header

The Host header is the only header that HTTP/1.1 requires in every request. It was introduced to support virtual hosting — multiple websites served from the same IP address and port.

Why It’s Required

Before HTTP/1.1, each website needed its own IP address. The Host header allows a server to distinguish between example.com and other.com even when both resolve to the same IP. Without it, the server has no way to determine which virtual host the request is for.

Rules

RFC 9112 §3.2 defines strict requirements:

  • A client MUST send a Host header in every HTTP/1.1 request.
  • A server MUST respond with 400 Bad Request if:
    • The Host header is missing.
    • There are multiple Host headers.
    • The Host value is invalid.
  • The Host value must match the URI authority (hostname and optional port).
GET / HTTP/1.1
Host: example.com
GET /api/data HTTP/1.1
Host: api.example.com:8443

Host vs :authority

In HTTP/2 and HTTP/3, the Host header is replaced by the :authority pseudo-header in the request. However, Host is still sent for backward compatibility with intermediaries.

Message SyntaxConnections