[Next] [Previous] [Up] [Top] [Full Contents] [Search]

5. Request

5.4 Request Header Fields

The request header fields allow the client to pass additional information about the request (and about the client itself) to the server. All header fields are optional and conform to the generic HTTP-header syntax.

Request-Header	=	Accept
	|	Accept-Charset
	|	Accept-Encoding
	|	Accept-Language
	|	Authorization
	|	From
	|	If-Modified-Since
	|	Pragma
	|	Referer
	|	User-Agent
	|	extension-header
Although additional request header fields may be implemented via the extension mechanism, applications which do not recognize those fields should treat them as Entity-Header fields.

5.4.1 Accept

The Accept header field can be used to indicate a list of media ranges which are acceptable as a response to the request. The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes of that type. The set of ranges given by the client should represent what types are acceptable given the context of the request. The Accept field should only be used when the request is specifically limited to a set of desired types (as in the case of a request for an in-line image), to indicate qualitative preferences for specific media types, or to indicate acceptance of unusual media types.

The field may be folded onto several lines and more than one occurrence of the field is allowed (with the semantics being the same as if all the entries had been in one field value).

Accept	=	"Accept" ":" 1#(
		     media-range
		     [ ";" "q" "=" ( "0" | "1" | float ) ]
		     [ ";" "mxb" "=" 1*DIGIT ] )
media-range	=	( "*/*"
	|	  ( type "/" "*" )
	|	  ( type "/" subtype )
		) *( ";" parameter )
float	=	< ANSI-C floating point text representation,
		where (0.0 < float < 1.0) >
The parameter q is used to indicate the quality factor, which represents the user's preference for that range of media types, and the parameter mxb gives the maximum acceptable size of the Entity-Body (in decimal number of octets) for that range of media types. Section 9 describes the content negotiation algorithm which makes use of these values. If at least one Accept header is present, a quality factor of 0 is equivalent to not sending an Accept header field containing that media-type or set of media-types. The default values are: q=1 and mxb=undefined (i.e. infinity).

The example

Accept: audio/*; q=0.2, audio/basic
should verbally be interpreted as "if you have audio/basic, send it; otherwise send me any audio type."

If no Accept header is present, then it is assumed that the client accepts all media types with quality factor 1. This is equivalent to the client sending the following accept header field:

Accept: */*; q=1
or

Accept: */*
A more elaborate example is

Accept: text/plain; q=0.5, text/html,
        text/x-dvi; q=0.8; mxb=100000, text/x-c
Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist then send the Entity-Body in text/x-dvi if the entity is less than 100000 bytes, otherwise send text/plain".

Note
In earlier versions of this document, the mxs parameter defined the maximum acceptable delay in seconds before the response would arrive. This has been removed as the server has no means of obtaining a useful reference value. However, this does not prevent the client from internally measuring the response time and optimizing the Accept header field accordingly.

It must be emphasized that this field should only be used when it is necessary to restrict the response media types to a subset of those possible, to indicate the acceptance of unusual media types, or when the user has been permitted to specify qualitative values for ranges of media types. If no quality factors have been set by the user, and the context of the request is such that the user agent is capable of saving the entity to a file if the received media type is unknown, then the only appropriate value for Accept is "*/*" and the list of unusual types. Whether or not a particular media type is deemed "unusual" should be a configurable aspect of the user agent.

5.4.2 Accept-Charset

The Accept-Charset header field can be used to indicate a list of preferred character sets other than the default US-ASCII and ISO-8859-1. This field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability to a server which is capable of representing documents in those character sets.

Accept-Charset	=	"Accept-Charset" ":" 1#charset
Character set values are described in Section 8.3. An example is

Accept-Charset: iso-8859-5, unicode-1-1
The value of this field should not include "US-ASCII" or "ISO-8859-1", since those values are always assumed by default. If a resource is only available in a character set other than the defaults, and that character set is not listed in the Accept-Charset field, it is only acceptable for the server to send the entity if the character set can be identified by an appropriate charset parameter on the media type or within the format of the media type itself.

Note
User agents are not required to be able to render the characters associated with the ISO-8859-1 character set. However, they must be able to interpret their meaning to whatever extent is required to properly handle messages in that character set..

5.4.3 Accept-Encoding

The Accept-Encoding header field is similar to Accept, but lists the encoding-mechanisms and transfer-encoding values which are acceptable in the response.

Accept-Encoding	=	"Accept-Encoding" ":" 
		1#( encoding-mechanism | transfer-encoding )
An example of its use is

Accept-Encoding: compress, base64, gzip, quoted-printable
The field value should never include the identity transfer-encoding values ("7bit", "8bit", and "binary") since they actually represent "no encoding." If no Accept-Encoding field is present in a request, it must be assumed that the client does not accept any encoding-mechanism and only the identity transfer-encodings.

5.4.4 Accept-Language

The Accept-Language header field is similar to Accept, but lists the set of natural languages that are preferred as a response to the request.

Accept-Language	=	"Accept-Language" ":" 1#language-tag
The language-tag is described in Section 8.2. Languages are listed in the order of their preference to the user. For example,

Accept-Language: dk, en-gb
would mean: "Send me a Danish version if you have it; else a British English version."

If the server cannot fulfill the request with one or more of the languages given, or if the languages only represent a subset of a multi-linguistic Entity-Body, it is acceptable to serve the request in an unspecified language.

Note
As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice of linguistic preference available to the user.

5.4.5 Authorization

A user agent that wishes to authenticate itself with a server (usually, but not necessarily, after receiving a "401 Unauthorized" response), may do so by including an Authorization header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

Authorization	=	"Authorization" ":" credentials
HTTP access authentication is described in Section 10. If a request is authenticated and a realm specified, the same credentials should be valid for all other requests within this realm.

5.4.6 From

The From header field, if given, should contain an Internet e-mail address for the human user who controls the requesting user agent. The address should be machine-usable, as defined by addr-spec in RFC 822:

From	=	"From" ":" addr-spec
An example is:

From: webmaster@w3.org
This header field may be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It should not be used as an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents should include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end.

The Internet e-mail address in this field does not have to correspond to the Internet host which issued the request. (For example, when a request is passed through a proxy, then the original issuer's address should be used). The address should, if possible, be a valid Internet e-mail address, whether or not it is in fact an Internet e-mail address or the Internet e-mail representation of an address on some other mail system.

Note
The client should not send the From header field without the user's approval, as it may conflict with the user's privacy interests or their site's security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at any time prior to a request.

5.4.7 If-Modified-Since

The If-Modified-Since header field is used with the GET method to make it conditional: if the requested resource has not been modified since the time specified in this field, a copy of the resource will not be returned from the server; instead, a "304 Not Modified" response will be returned without any Entity-Body.

If-Modified-Since	=	"If-Modified-Since" ":" HTTP-date
An example of the field is:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
The purpose of this feature is to allow efficient updates of local cache information with a minimum amount of transaction overhead. The same functionality can be obtained, though with much greater overhead, by issuing a HEAD request and following it with a GET request if the server indicates that the entity has been modified.

5.4.8 Pragma

The Pragma header field is used to specify directives that must be applied to all servers along the request chain (where relevant). The directives typically specify behavior that prevents intermediate proxies from changing the nature of the request. Although multiple pragma directives can be listed as part of the request, HTTP/1.0 only defines semantics for the
"no-cache" directive.

Pragma	=	"Pragma" ":" 1#pragma-directive
pragma-directive	=	"no-cache" | extension-pragma
extension-pragma	=	token
When the "no-cache" directive is present, a caching proxy must forward the request toward the origin server even if it has a cached copy of what is being requested. This allows a client to insist upon receiving an authoritative response to its request. It also allows a client to refresh a cached copy which has become corrupted or is known to be stale.

Pragmas must be passed through by a proxy even when they have significance to that proxy. This is necessary in cases when the request has to go through many proxies, and the pragma may affect all of them. It is not possible to specify a pragma for a specific proxy; however, any pragma-directive not relevant to a gateway or proxy should be ignored.

5.4.9 Referer

The Referer field allows the client to specify, for the server's benefit, the address (URI) of the document (or element within the document) from which the Request-URI was obtained. This allows a server to generate lists of back-links to documents, for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The format of the field is:

Referer	=	"Referer" ":" URI
Example:

Referer: http://info.cern.ch/hypertext/DataSources/Overview.html
If a partial URI is given, it should be interpreted relative to the Request-URI.

Note
Because the source of a link may be considered private information or may reveal an otherwise secure information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information.

5.4.10 User-Agent

The User-Agent field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. Although it is not required, user agents should always include this field with requests. The field can contain multiple tokens specifying the product name, with an optional slash and version designator, and other products which form a significant part of the user agent. By convention, the products are listed in order of their significance for identifying the application.

User-Agent	=	"User-Agent" ":" 1*( product )
product	=	token ["/" product-version]
product-version	=	token
Example:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Product tokens should be short and to the point -- use of this field for advertizing or other non-essential information is explicitly deprecated and will be considered as non-conformance to the protocol. Although any token character may appear in a product-version, this token should only be used for a version identifier (i.e., successive versions of the same product should only differ in the product-version portion of the product value). The User-Agent field may include additional information within comments that are not part of the value of the field.

Note
Some current proxy applications append their product information to the list in the User-Agent field. This is no longer recommended, since it makes machine interpretation of these fields ambiguous. Instead, proxies should use the Forwarded header described in Section 4.3.2.

T. Berners-Lee, R. T. Fielding, H. Frystyk Nielsen - 12 MAR 95

[Next] [Previous] [Up] [Top] [Full Contents] [Search]

Generated with CERN WebMaker