Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
316 lines (255 sloc) 32 KB



For the purposes of HTTP, a "representation" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol, and that consists of a set of representation metadata and a potentially unbounded stream of representation data.

Continue reading on RFC7231#3


Representation header fields provide metadata about the representation. When a message includes a payload body, the representation header fields describe how to interpret the representation data enclosed in the payload body.

Continue reading on RFC7231#3.1

header description spec
Content-Encoding "indicates what content codings have been applied to the representation, beyond those inherent in the media type, and thus what decoding mechanisms have to be applied in order to obtain data in the media type referenced by the Content-Type header field." RFC7231#,
Content-Language "describes the natural language(s) of the intended audience for the representation." RFC7231#,
Content-Location "references a URI that can be used as an identifier for a specific resource corresponding to the representation in this message's payload." RFC7231#,
Content-Type "indicates the media type of the associated representation: either the representation enclosed in the message payload or the selected representation, as determined by the message semantics." RFC7231#,


The representation data associated with an HTTP message is either provided as the payload body of the message or referred to by the message semantics and the effective request URI.

Continue reading on RFC7231#3.2

header description spec
Content-Length "can provide the anticipated size, as a decimal number of octets, for a potential payload body." RFC7230#3.3.2,
Content-Range "is sent in a single part 206 (Partial Content) response to indicate the partial range of the selected representation enclosed as the message payload, sent in each part of a multipart 206 response to indicate the range enclosed within each body part, and sent in 416 (Range Not Satisfiable) responses to provide information about the selected representation." RFC7233#4.2,
Transfer-Encoding "lists the transfer coding names corresponding to the sequence of transfer codings that have been (or will be) applied to the payload body in order to form the message body." RFC7230#3.3.1,


A client sends request header fields to provide more information about the request context, make the request conditional based on the target resource state, suggest preferred formats for the response, supply authentication credentials, or modify the expected request processing.

Continue reading on RFC7231#5


Controls are request header fields that direct specific handling of the request.

Continue reading on RFC7231#5.1

header description spec
Cache-Control "is used to specify directives for caches along the request/response chain." RFC7234#7.2,
Expect "is used to indicate that particular server behaviors are required by the client." RFC7231#5.1.1,
Host "provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple host names on a single IP address." RFC7230#5.4,
HTTP2-Settings "A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly one HTTP2-Settings header field. The HTTP2-Settings header field is a connection-specific header field that includes parameters that govern the HTTP/2 connection, provided in anticipation of the server accepting the request to upgrade." RFC7540#3.2.1
Max-Forwards "provides a mechanism with the TRACE and OPTIONS methods to limit the number of times that the request is forwarded by proxies." RFC7231#5.1.2,
Pragma "allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request that they will understand (as Cache-Control was not defined until HTTP/1.1)." RFC7234#7.4,
Range "modifies the method semantics to request transfer of only one or more subranges of the selected representation data, rather than the entire selected representation data." RFC7233#3.1,
TE "indicates what transfer codings, besides chunked, the client is willing to accept in response, and whether or not the client is willing to accept trailer fields in a chunked transfer coding." RFC7230#4.3,


The HTTP conditional request header fields [Part4] allow a client to place a precondition on the state of the target resource, so that the action corresponding to the method semantics will not be applied if the precondition evaluates to false.

Continue reading on RFC7231#5.2

header description spec
If-Match "can be used to make a request method conditional on the current existence or value of an entity-tag for one or more representations of the target resource." RFC7232#3.1,
If-Modified-Since "can be used with GET or HEAD to make the method conditional by modification date: if the selected representation has not been modified since the time specified in this field, then do not perform the request method; instead, respond as detailed below." RFC7232#3.3,
If-None-Match "can be used to make a request method conditional on not matching any of the current entity-tag values for representations of the target resource." RFC7232#3.2,
If-Range "Informally, its meaning is: if the representation is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation." RFC7233#3.2,
If-Unmodified-Since "can be used to make a request method conditional by modification date: if the selected representation has been modified since the time specified in this field, then the server MUST NOT perform the requested operation and MUST instead respond with the 412 (Precondition Failed) status code." RFC7232#3.4,

Content Negotiation

The preferences sent in these fields apply to any content in the response, including representations of the target resource, representations of error or processing status, and potentially even the miscellaneous text strings that might appear within the protocol.

Continue reading on RFC7231#5.3

header description spec
Accept "can be used to specify certain media types which are acceptable for the response." RFC7231#5.3.2,
Accept-Charset "can be sent by a user agent to indicate what charsets are acceptable in textual response content." RFC7231#5.3.3,
Accept-Encoding "can be used by user agents to indicate what response content-codings are acceptable in the response." RFC7231#5.3.4,
Accept-Language "can be used by user agents to indicate the set of natural languages that are preferred in the response." RFC7231#5.3.5,

Authentication Credentials

Two header fields are used for carrying authentication credentials

Continue reading on RFC7231#5.4

header description spec
Authorization "allows a user agent to authenticate itself with a server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response." RFC7235#4.1,
Proxy-Authorization "allows the client to identify itself (or its user) to a proxy that requires authentication." RFC7235#4.3,

Request Context

request header fields provide additional information about the request context, including information about the user, user agent, and resource behind the request.

Continue reading on RFC7231#5.5

header description spec
DNT "defined as the means for expressing a user's tracking preference via HTTP." Tracking Preference Expression (DNT)
From "contains an Internet email address for a human user who controls the requesting user agent." RFC7231#5.5.1,
Referer "allows the user agent to specify a URI reference for the resource from which the target URI was obtained (i.e., the "referrer", though the field name is misspelled)." RFC7231#5.5.2,
User-Agent "contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use." RFC7231#5.5.3,


The response header fields allow the server to pass additional information about the response beyond what is placed in the status-line.

Continue reading on RFC7231#7

Control Data

Response header fields can supply control data that supplements the status code, directs caching, or instructs the client where to go next.

Continue reading on RFC7231#7.1

header description spec
Age "conveys the sender's estimate of the amount of time since the response was generated or successfully validated at the origin server." RFC7234#5.1,
Cache-Control "is used to specify directives for caches along the request/response chain." RFC7234#7.2,
Expires "gives the date/time after which the response is considered stale." RFC7234#7.3,
Date "represents the date and time at which the message was originated" RFC7231#,
Location "is used in some responses to refer to a specific resource in relation to the response." RFC7231#7.1.2,
Retry-After "indicates how long the user agent ought to wait before making a follow-up request." RFC7231#7.1.3,
Tk "defined as an OPTIONAL means for indicating the tracking status that applied to the corresponding request and as a REQUIRED means for indicating that a state-changing request has resulted in an interactive change to the tracking status. " Tracking Preference Expression (DNT)
Vary "describes what parts of a request message, aside from the method and request target, might influence the origin server's process for selecting and representing the response." RFC7231#7.1.4,
Warning "is used to carry additional information about the status or transformation of a message that might not be reflected in the message." RFC7234#7.6,


Validator header fields convey metadata about the selected representation

Continue reading on RFC7231#7.2

header description spec
ETag "provides the current entity-tag for the selected representation, as determined at the conclusion of handling the request." RFC7232#2.3,
Last-Modified "provides a timestamp indicating the date and time at which the origin server believes the selected representation was last modified, as determined at the conclusion of handling the request." RFC7232#2.2,

Authentication Challenges

Continue reading on RFC7231#7.3

header description spec
WWW-Authenticate "consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the effective request URI." RFC7235#4.4,
Proxy-Authenticate "consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the proxy for this effective request URI." RFC7235#4.2,

Response Context

Continue reading on RFC7231#7.4

header description spec
Accept-Ranges "allows a server to indicate that it supports range requests for the target resource." RFC7233#2.3,
Allow "lists the set of methods advertised as supported by the target resource." RFC7231#7.4.1,
Server "contains information about the software used by the origin server to handle the request, which is often used by clients to help identify the scope of reported interoperability problems, to work around or tailor requests to avoid particular server limitations, and for analytics regarding server or operating system use." RFC7231#7.4.2,

Common (subjective)

header description spec
Accept-Patch "used to specify the patch document formats accepted by the server." RFC5789#3.1
Accept-Post "indicates server support for specific media types for entity bodies in HTTP POST requests." draft-wilde-accept-post
Access-Control-Allow-Credentials "indicates whether the response to request can be exposed when the omit credentials flag is unset" CORS
Access-Control-Allow-Headers "indicates, as part of the response to a preflight request, which header field names can be used during the actual request" CORS
Access-Control-Allow-Methods "indicates, as part of the response to a preflight request, which methods can be used during the actual request" CORS
Access-Control-Allow-Origin "indicates whether a resource can be shared" CORS
Access-Control-Expose-Headers "indicates which headers are safe to expose to the API of a CORS API specification" CORS
Access-Control-Max-Age "indicates how long the results of a preflight request can be cached in a preflight result cache" CORS
Access-Control-Request-Headers "indicates which headers will be used in the actual request as part of the preflight request" CORS
Access-Control-Request-Method "indicates which method will be used in the actual request as part of the preflight request" CORS
Connection "" ?
Content-Disposition "standard" RFC6266
Content-MD5 "" ?
Content-Security-Policy "is the preferred mechanism for delivering a CSP policy" CSP
Content-Security-Policy-Report-Only "lets servers experiment with policies by monitoring (rather than enforcing) a policy" CSP
Cookie "standard" RFC6265
Digest "" ?
Forwarded "standard" RFC7239
Keep-Alive "" ?
Link "provides a means for serialising one or more links in HTTP headers." RFC5988#5
Origin "standard" RFC6454
Prefer "is used to indicate that particular server behaviors are preferred by the client, but not required for successful completion of the request." RFC7240#2
Preference-Applied "MAY be included within a response message as an indication as to which Prefer tokens were honored by the server and applied to the processing of a request." RFC7240#3
Set-Cookie "standard" RFC6265
Strict-Transport-Security "standard" RFC6797
Variant-Vary "" ?
Via "" RFC7230#5.7.1,

Less Common (subjective)

header description spec
A-IM "" RFC3229#10.5.3
Accept-Additions "" ?
Accept-CH "advertise support for Client Hints" draft-grigorik-http-client-hints
Accept-Features "can be used by a user agent to give information about the presence or absence of certain features in the feature set of the current request." RFC2295#8.2
ALPN "indicates the application-layer protocol that a client intends to use within the tunnel, or a set of protocols that might be used within the tunnel." RFC7639#2
Alt-Svc "is advertising the availability of alternate services to HTTP/1.1 and HTTP/2.0 clients by adding an Alt-Svc header field to responses." draft-nottingham-httpbis-alt-svc
Alternates "is used to convey the list of variants bound to a negotiable resource." RFC2295#8.3
Apply-To-Redirect-Ref "" RFC4437
Authentication-Info "" ?
C-Ext "" ?
CH "describes an example list of client preferences that the server can use to adapt and optimize the resource to satisfy a given request." draft-grigorik-http-client-hints
C-Man "" ?
C-Opt "" ?
C-PEP "" ?
C-PEP-Info "" ?
Content-Base "obsoleted" RFC2068,
Content-DPR "is a number that indicates the ratio between physical pixels over CSS px of the selected image response." draft-grigorik-http-client-hints
Content-ID "" ?
Content-Script-Type "" ?
Content-Style-Type "" ?
Content-Version "" ?
Cookie2 "obsoleted" RFC2965,
DASL "standard" RFC5323
DAV "standard" RFC4918
Default-Style "" ?
Delta-Base "" RFC3229#10.5.1
Depth "standard" RFC4918
Derived-From "" ?
Destination "standard" RFC4918
Differential-ID "" ?
DPR "is a number that, in requests, indicates the client’s current Device Pixel Ratio (DPR), which is the ratio of physical pixels over CSS px of the layout viewport on the device." draft-grigorik-http-client-hints
Encryption "describes the encrypted content encoding(s) that have been applied to a payload body, and therefore how those content encoding(s) can be removed." draft-thomson-http-encryption
Encryption-Key "can be used to describe the input keying material used in the Encryption header field." draft-thomson-http-encryption
Ext "" ?
GetProfile "" ?
IM "" RFC3229#10.5.2
If "standard" RFC4918
If-Schedule-Tag-Match "standard" RFC6638
Key "allows an origin server to describe the cache key for a negotiated response: a short algorithm that can be used upon later requests to determine if the same response is reusable." draft-fielding-http-key
Label "" ?
Last-Event-ID "The value of the event source's last event ID string, encoded as UTF-8." Server-Sent Events
Link-Template "provides a means for serialising one or more links into HTTP headers." draft-nottingham-link-template
Lock-Token "standard" RFC4918
Man "" ?
MD "is a number that, in requests, indicates the client’s maximum downlink speed in megabits per second (Mbps), which is the standardized, or generally accepted, maximum download data rate for the underlying connection technology in use by the client." draft-grigorik-http-client-hints
Meter "" ?
MIME-Version "" ?
Negotiate "can contain directives for any content negotiation process initiated by the request." RFC2295#8.4
Nice "indicates that a request is less important than a request that doesn't bear this header." draft-thomson-http-nice
Opt "" ?
Ordering-Type "standard" ?
Overwrite "standard" RFC4918
P3P "" ?
PEP "" ?
PICS-Label "" ?
Pep-Info "" ?
POE "The POE HTTP header is a request-header field whose field-value indicates the version of POE that a client supports." draft-nottingham-http-poe
POE-Links "The POE-Links HTTP header is an entity-header field whose field-value is a comma-separated list of quoted URI-references (without fragment identifiers) that the origin server asserts to be POE resources. The contents of the POE-Links response header SHOULD correspond to links found in the content of the response body." draft-nottingham-http-poe
Position "standard" ?
ProfileObject "" ?
Protocol "" ?
Protocol-Info "" ?
Protocol-Query "" ?
Protocol-Request "" ?
Proxy-Authentication-Info "" ?
Proxy-Features "" ?
Proxy-Instruction "" ?
Public "" ?
Redirect-Ref "" RFC4437
RW "is a number that, in requests, indicates the Resource Width (RW) in CSS px, which is either the display width of the requested resource (e.g. display width of an image), or the layout viewport width if the resource does not have a display width (e.g. a non-image asset)." draft-grigorik-http-client-hints
Safe "" ?
Schedule-Reply "standard" RFC6638
Schedule-Tag "standard" RFC6638
Sec-WebSocket-Accept "standard" RFC6455
Sec-WebSocket-Extensions "standard" RFC6455
Sec-WebSocket-Key "standard" RFC6455
Sec-WebSocket-Protocol "standard" RFC6455
Sec-WebSocket-Version "standard" RFC6455
Security-Scheme "" ?
Set-Cookie2 "obsoleted" RFC2965,
SetProfile "" ?
SLUG "standard" RFC5023
SoapAction "" ?
Status-URI "" RFC2518
Sunset "allows a server to communicate the fact that a resource is expected to become unresponsive at a specific point in time." draft-wilde-sunset-header
Surrogate-Capability "" Edge Architecture
Surrogate-Control "" Edge Architecture
TCN "is used by a server to signal that the resource is transparently negotiated." RFC2295#8.5
Timeout "standard" RFC4918
Trailer "" 43
URI "" ?
Upgrade "" 42
Variant-Vary "can be used in a choice response to record any vary information which applies to the variant data (the entity body combined with some of the entity headers) contained in the response, rather than to the response as a whole." RFC2295#8.6
Want-Digest "" ?
X-Frame-Options "indicates a policy that specifies whether the browser should render the transmitted resource within a <frame> or an <iframe>. Servers can declare this policy in the header of their HTTP responses to prevent clickjacking attacks, which ensures that their content is not embedded into other pages or frames." RFC7034

A chunk of provisional headers can be found at HTTP Headers Registry.

For a full up-to-date list, including non-HTTP headers, continue reading on HTTP Headers Registry, Wikipedia.