Headers

3.5 Headers

Headers and methods work together to determine what clients and servers do. This section 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). Appendix C summarizes all these headers in more detail.

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 five main classes:

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 

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:

 Accept: */* 

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 Tiki-Hut server:

 Server: Tiki-Hut/1.0 

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 

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.

3.5.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. Table 3-11 lists the general informational headers.

Table 3-11. General informational headers
Header	Description
Connection	Allows clients and servers to specify options about the request/response connection
Date [4]	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 [5]
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

^[4] Date lists the acceptable date formats for the Date header.

^[5] Chunked transfer codings are discussed further in Section 15.6.3.1 .

3.5.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. In Chapter 7 , we cover caching in depth. Table 3-12 lists the basic caching headers.

Table 3-12. General caching headers
Header	Description
Cache-Control	Used to pass caching directions along with the message
Pragma [6]	Another way to pass directions along with the message, though not specific to caching

^[6] Pragma technically is a request header. It was never specified for use in responses. Because of its common misuse as a response header, many clients and proxies will interpret Pragma as a response header, but the precise semantics are not well defined. In any case, Pragma is deprecated in favor of Cache-Control.

3.5.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. Table 3-13 lists the request informational headers.

Table 3-13. Request informational headers
Header	Description
Client-IP [7]	Provides the IP address of the machine on which the client is running
From	Provides the email address of the client's user [8]
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 [9]	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

^[7] Client-IP and the UA-* headers are not defined in RFC 2616 but are implemented by many HTTP client applications.

^[8] An RFC 822 email address format.

^[9] While implemented by some clients, the UA-* headers can be considered harmful . Content, specifically HTML, should not be targeted at specific client configurations.

3.5.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. Table 3-14 lists the various accept headers.

Table 3-14. Accept headers
Header	Description
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 [10]	Tells the server what extension transfer codings are okay to use

^[10] See Section 15.6.2 for more on the TE header.

3.5.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. Table 3-15 lists the various conditional request headers.

Table 3-15. Conditional request headers
Header	Description
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 [11]
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 [12]

^[11] See Chapter 7 for more on entity tags. The tag is basically an identifier for a version of the resource.

^[12] See Section 15.9 for more on the Range header.

3.5.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. We discuss this challenge/response scheme in Chapter 14 , along with other security schemes that have been implemented on top of HTTP. Table 3-16 lists the request security headers.

Table 3-16. Request security headers
Header	Description
Authorization	Contains the data the client is supplying to the server to authenticate itself
Cookie	Used by clients to pass a token to the servernot a true security header, but it does have security implications [13]
Cookie2	Used to note the version of cookies a requestor supports; see Section 11.6.7

^[13] The Cookie header is not defined in RFC 2616; it is discussed in detail in Chapter 11 .

3.5.2.4 Proxy request headers

As proxies become increasingly common on the Internet, a few headers have been defined to help them function better. In Chapter 6 , we discuss these headers in detail. Table 3-17 lists the proxy request headers.

Table 3-17. Proxy request headers
Header	Description
Max-Forwards	The maximum number of times a request should be forwarded to another proxy or gateway on its way to the origin serverused with the TRACE method [14]
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

^[14] See Section 6.6.2.1 .

3.5.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. Table 3-18 lists the response informational headers.

Table 3-18. Response informational headers
Header	Description
Age	How old the response is [15]
Public [16]	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 [17]	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

^[15] Implies that the response has traveled through an intermediary, possibly from a proxy cache.

^[16] The Public header is defined in RFC 2068 but does not appear in the latest HTTP definition (RFC 2616).

^[17] The Title header is not defined in RFC 2616; see the original HTTP/1.0 draft definition ( http://www.w3.org/Protocols/HTTP/HTTP2.html ).

3.5.3.1 Negotiation headers

HTTP/1.1 provides servers and clients with the ability to negotiate for a resource if multiple representations are availablefor instance, when there are both French and German translations of an HTML document on a server. Chapter 17 walks through negotiation in detail. Here are a few headers servers use to convey information about resources that are negotiable. Table 3-19 lists the negotiation headers.

Table 3-19. Negotiation headers
Header	Description
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.5.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. We talk about security in detail in Chapter 14 . For now, here are the basic challenge headers. Table 3-20 lists the response security headers.

Table 3-20. Response security headers
Header	Description
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 [18]
Set-Cookie2	Similar to Set-Cookie, RFC 2965 Cookie definition; see Section 11.6.7
WWW-Authenticate	A list of challenges for the client from the server

^[18] Set-Cookie and Set-Cookie2 are extension headers that are also covered in Chapter 11 .

3.5.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. Table 3-21 lists the entity informational headers.

Table 3-21. Entity informational headers
Header	Description
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

3.5.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. Table 3-22 lists the various content headers.

Table 3-22. Content headers
Header	Description
Content-Base [19]	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

^[19] The Content-Base header is not defined in RFC 2616.

3.5.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 cachedfor 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.

In Chapter 7 , we dive deep into the heart of caching HTTP requests and responses. We will see these headers again there. Table 3-23 lists the entity caching headers.

Table 3-23. Entity caching headers
Header	Description
ETag	The entity tag associated with this entity [20]
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

^[20] Entity tags are basically identifiers for a particular version of a resource.