Headers and methods work together to determine what clients and servers do. This article quickly sketches the purposes of the standard HTTP headers and some headers that are not explicitly defined in the HTTP/1.1 specification (RFC 2616).
There are headers that are specific for each type of message and headers that are more general in purpose, providing information in both request and response messages. Headers fall into 5 main classes:
1. General headers
These are generic headers used by both clients and servers. They serve general purposes that are useful for clients, servers, and other applications to supply to one another. For example, the Date header is a general-purpose header that allows both sides to indicate the time and date at which the message was constructed:
Date: Tue, 3 Oct 1974 02:16:00 GMT
2. Request headers
As the name implies, request headers are specific to request messages. They provide extra information to servers, such as what type of data the client is willing to receive. For example, the following Accept header tells the server that the client will accept any media type that matches its request:
3. Response headers
Response messages have their own set of headers that provide information to the client (e.g., what type of server the client is talking to). For example, the following Server header tells the client that it is talking to a Version 1.0 python server:
4. Entity headers
Entity headers refer to headers that deal with the entity body. For instance, entity headers can tell the type of the data in the entity body. For example, the following Content-Type header lets the application know that the data is an HTML document in the iso-latin-1 character set:
Content-Type: text/html; charset=iso-latin-1
5. Extension headers
Extension headers are nonstandard headers that have been created by application developers but not yet added to the sanctioned HTTP specification. HTTP programs need to tolerate and forward extension headers, even if they don’t know what the headers mean.
1. General Headers
Some headers provide very basic information about a message. These headers are called general headers. They are the fence straddlers, supplying useful information about a message regardless of its type.
For example, whether you are constructing a request message or a response message, the date and time the message is created means the same thing, so the header that provides this kind of information is general to both types of messages.
|Connection||Allows clients and servers to specify options about the request/response connection|
|Date||Provides a date and time stamp telling when the message was created|
|MIME-Version||Gives the version of MIME that the sender is using|
|Trailer||Lists the set of headers that are in the trailer of a message encoded with the chunked transfer encoding|
|Transfer-Encoding||Tells the receiver what encoding was performed on the message in order for it to be transported safely|
|Upgrade||Gives a new version or protocol that the sender would like to “upgrade” to using|
|Via||Shows what intermediaries (proxies, gateways) the message has gone through|
1.1 General caching headers
HTTP/1.0 introduced the first headers that allowed HTTP applications to cache local copies of objects instead of always fetching them directly from the origin server. The latest version of HTTP has a very rich set of cache parameters.
|Cache-Control||Used to pass caching directions along with the message|
|Pragma||Another way to pass directions along with the message, though not specific to caching|
2. Request Headers
Request headers are headers that make sense only in a request message. They give information about who or what is sending the request, where the request originated, or what the preferences and capabilities of the client are. Servers can use the information the request headers give them about the client to try to give the client a better response.
|Client-IP||Provides the IP address of the machine on which the client is running|
|From||Provides the email address of the client’s user|
|Host||Gives the hostname and port of the server to which the request is being sent|
|Referer||Provides the URL of the document that contains the current request URI|
|UA-Color||Provides information about the color capabilities of the client machine’s display|
|UA-CPU||Gives the type or manufacturer of the client’s CPU|
|UA-Disp||Provides information about the client’s display (screen) capabilities|
|UA-OS||Gives the name and version of operating system running on the client machine|
|UA-Pixels||Provides pixel information about the client machine’s display|
|User-Agent||Tells the server the name of the application making the request|
2.1 Accept headers
Accept headers give the client a way to tell servers their preferences and capabilities: what they want, what they can use, and, most importantly, what they don’t want. Servers can then use this extra information to make more intelligent decisions about what to send. Accept headers benefit both sides of the connection. Clients get what they want, and servers don’t waste their time and bandwidth sending something the client can’t use.
|Accept||Tells the server what media types are okay to send|
|Accept-Charset||Tells the server what charsets are okay to send|
|Accept-Encoding||Tells the server what encodings are okay to send|
|Accept-Language||Tells the server what languages are okay to send|
|TE||Tells the server what extension transfer codings are okay to use|
2.2 Conditional request headers
Sometimes, clients want to put some restrictions on a request. For instance, if the client already has a copy of a document, it might want to ask a server to send the document only if it is different from the copy the client already has. Using conditional request headers, clients can put such restrictions on requests, requiring the server to make sure that the conditions are true before satisfying the request.
|Expect||Allows a client to list server behaviors that it requires for a request|
|If-Match||Gets the document if the entity tag matches the current entity tag for the document|
|If-Modified-Since||Restricts the request unless the resource has been modified since the specified date|
|If-None-Match||Gets the document if the entity tags supplied do not match those of the current document|
|If-Range||Allows a conditional request for a range of a document|
|If-Unmodified-Since||Restricts the request unless the resource has not been modified since the specified date|
|Range||Requests a specific range of a resource, if the server supports range requests|
2.3 Request security headers
HTTP natively supports a simple challenge/response authentication scheme for requests. It attempts to make transactions slightly more secure by requiring clients to authenticate themselves before getting access to certain resources.
|Authorization||Contains the data the client is supplying to the server to authenticate itself|
|Cookie||Used by clients to pass a token to the server – not a true security header, but it does have security implications|
|Cookie2||Used to note the version of cookies a requestor supports|
2.4 Proxy request headers
As proxies become increasingly common on the Internet, a few headers have been defined to help them function better.
|Max-Forwards||The maximum number of times a request should be forwarded to another proxy or gateway on its way to the origin server – used with the TRACE method|
|Proxy-Authorization||Same as Authorization, but used when authenticating with a proxy|
|Proxy-Connection||Same as Connection, but used when establishing connections with a proxy|
3. Response Headers
Response messages have their own set of response headers. Response headers provide clients with extra information, such as who is sending the response, the capabilities of the responder, or even special instructions regarding the response. These headers help the client deal with the response and make better requests in the future.
|Age||How old the response is|
|Public||A list of request methods the server supports for its resources|
|Retry-After||A date or time to try back, if a resource is unavailable|
|Server||The name and version of the server’s application software|
|Title||For HTML documents, the title as given by the HTML document source|
|Warning||A more detailed warning message than what is in the reason phrase|
3.1 Negotiation headers
HTTP/1.1 provides servers and clients with the ability to negotiate for a resource if multiple representations are available—for instance, when there are both French and German translations of an HTML document on a server.
|Accept-Ranges||The type of ranges that a server will accept for this resource|
|Vary||A list of other headers that the server looks at and that may cause the response to vary; i.e., a list of headers the server looks at to pick which is the best version of a resource to send the client|
3.2 Response security headers
You’ve already seen the request security headers, which are basically the response side of HTTP’s challenge/response authentication scheme.
|Proxy-Authenticate||A list of challenges for the client from the proxy|
|Set-Cookie||Not a true security header, but it has security implications; used to set a token on the client side that the server can used to identify the client|
|Set-Cookie2||Similar to Set-Cookie|
|WWW-Authenticate||A list of challenges for the client from the server|
4. Entity Headers
There are many headers to describe the payload of HTTP messages. Because both request and response messages can contain entities, these headers can appear in either type of message. Entity headers provide a broad range of information about the entity and its content, from information about the type of the object to valid request methods that can be made on the resource. In general, entity headers tell the receiver of the message what it’s dealing with.
|Allow||Lists the request methods that can be performed on this entity|
|Location||Tells the client where the entity really is located; used in directing the receiver to a (possibly new) location (URL) for the resource|
4.1 Content headers
The content headers provide specific information about the content of the entity, revealing its type, size, and other information useful for processing it. For instance, a web browser can look at the content type returned and know how to display the object.
|Content-Base||The base URL for resolving relative URLs within the body|
|Content-Encoding||Any encoding that was performed on the body|
|Content-Language||The natural language that is best used to understand the body|
|Content-Length||The length or size of the body|
|Content-Location||Where the resource actually is located|
|Content-MD5||An MD5 checksum of the body|
|Content-Range||The range of bytes that this entity represents from the entire resource|
|Content-Type||The type of object that this body is|
4.2 Entity caching headers
The general caching headers provide directives about how or when to cache. The entity caching headers provide information about the entity being cached – for example, information needed to validate whether a cached copy of the resource is still valid and hints about how better to estimate when a cached resource may no longer be valid.
|ETag||The entity tag associated with this entity|
|Expires||The date and time at which this entity will no longer be valid and will need to be fetched from the original source|
|Last-Modified||The last date and time when this entity changed|