Header Field Definitions / RFC 2068
This section defines the syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields, both sender and
recipient refer to either the client or the server, depending on who
sends and who receives the entity.
14.1 Accept
The Accept request-header field can be used to specify certain media
types which are acceptable for the response. Accept headers can be
used to indicate that the request is specifically limited to a small
set of desired types, as in the case of a request for an in-line
image.
Accept = "Accept" ":"
#( media-range [ accept-params ] )
media-range = ( "*/*"
| ( type "/" "*" )
| ( type "/" subtype )
) *( ";" parameter )
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
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 media-range MAY include media type
parameters that are applicable to that range.
Each media-range MAY be followed by one or more accept-params,
beginning with the "q" parameter for indicating a relative quality
factor. The first "q" parameter (if any) separates the media-range
parameter(s) from the accept-params. Quality factors allow the user
or user agent to indicate the relative degree of preference for that
media-range, using the qvalue scale from 0 to 1 (section 3.9). The
default value is q=1.
Note: Use of the "q" parameter name to separate media type
parameters from Accept extension parameters is due to historical
practice. Although this prevents any media type parameter named
"q" from being used with a media range, such an event is believed
to be unlikely given the lack of any "q" parameters in the IANA
media type registry and the rare usage of any media type parameters
in Accept. Future media types should be discouraged from
registering any parameter named "q".
The example
Accept: audio/*; q=0.2, audio/basic
SHOULD be interpreted as "I prefer audio/basic, but send me any audio
type if it is the best available after an 80% mark-down in quality."
If no Accept header field is present, then it is assumed that the
client accepts all media types. If an Accept header field is present,
and if the server cannot send a response which is acceptable
according to the combined Accept field value, then the server SHOULD
send a 406 (not acceptable) response.
A more elaborate example is
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, 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
text/x-dvi entity, and if that does not exist, send the text/plain
entity."
Media ranges can be overridden by more specific media ranges or
specific media types. If more than one media range applies to a given
type, the most specific reference has precedence. For example,
Accept: text/*, text/html, text/html;level=1, */*
have the following precedence:
1) text/html;level=1
2) text/html
3) text/*
4) */*
The media type quality factor associated with a given type is
determined by finding the media range with the highest precedence
which matches that type. For example,
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, */*;q=0.5
would cause the following values to be associated:
text/html;level=1 = 1
text/html = 0.7
text/plain = 0.3
image/jpeg = 0.5
text/html;level=2 = 0.4
text/html;level=3 = 0.7
Note: A user agent may be provided with a default set of quality
values for certain media ranges. However, unless the user agent is
a closed system which cannot interact with other rendering agents,
this default set should be configurable by the user.
14.2 Accept-Charset
The Accept-Charset request-header field can be used to indicate what
character sets are acceptable for the response. 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. The ISO-
8859-1 character set can be assumed to be acceptable to all user
agents.
Accept-Charset = "Accept-Charset" ":"
1#( charset [ ";" "q" "=" qvalue ] )
Character set values are described in section 3.4. Each charset may
be given an associated quality value which represents the user's
preference for that charset. The default value is q=1. An example is
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
If no Accept-Charset header is present, the default is that any
character set is acceptable. If an Accept-Charset header is present,
and if the server cannot send a response which is acceptable
according to the Accept-Charset header, then the server SHOULD send
an error response with the 406 (not acceptable) status code, though
the sending of an unacceptable response is also allowed.
14.3 Accept-Encoding
The Accept-Encoding request-header field is similar to Accept, but
restricts the content-coding values (section 14.12) which are
acceptable in the response.
Accept-Encoding = "Accept-Encoding" ":"
#( content-coding )
An example of its use is
Accept-Encoding: compress, gzip
If no Accept-Encoding header is present in a request, the server MAY
assume that the client will accept any content coding. If an Accept-
Encoding header is present, and if the server cannot send a response
which is acceptable according to the Accept-Encoding header, then the
server SHOULD send an error response with the 406 (Not Acceptable)
status code.
An empty Accept-Encoding value indicates none are acceptable.
14.4 Accept-Language
The Accept-Language request-header field is similar to Accept, but
restricts the set of natural languages that are preferred as a
response to the request.
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
Each language-range MAY be given an associated quality value which
represents an estimate of the user's preference for the languages
specified by that range. The quality value defaults to "q=1". For
example,
Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and
other types of English." A language-range matches a language-tag if
it exactly equals the tag, or if it exactly equals a prefix of the
tag such that the first tag character following the prefix is "-".
The special range "*", if present in the Accept-Language field,
matches every tag not matched by any other range present in the
Accept-Language field.
Note: This use of a prefix matching rule does not imply that
language tags are assigned to languages in such a way that it is
always true that if a user understands a language with a certain
tag, then this user will also understand all languages with tags
for which this tag is a prefix. The prefix rule simply allows the
use of prefix tags if this is the case.
The language quality factor assigned to a language-tag by the
Accept-Language field is the quality value of the longest language-
range in the field that matches the language-tag. If no language-
range in the field matches the tag, the language quality factor
assigned is 0. If no Accept-Language header is present in the
request, the server SHOULD assume that all languages are equally
acceptable. If an Accept-Language header is present, then all
languages which are assigned a quality factor greater than 0 are
acceptable.
It may be contrary to the privacy expectations of the user to send an
Accept-Language header with the complete linguistic preferences of
the user in every request. For a discussion of this issue, see
section 15.7.
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. If the choice is not
made available, then the Accept-Language header field must not be
given in the request.
14.5 Accept-Ranges
The Accept-Ranges response-header field allows the server to indicate
its acceptance of range requests for a resource:
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
acceptable-ranges = 1#range-unit | "none"
Origin servers that accept byte-range requests MAY send
Accept-Ranges: bytes
but are not required to do so. Clients MAY generate byte-range
requests without having received this header for the resource
involved.
Servers that do not accept any kind of range request for a resource
MAY send
Accept-Ranges: none
to advise the client not to attempt a range request.
14.6 Age
The Age response-header field conveys the sender's estimate of the
amount of time since the response (or its revalidation) was generated
at the origin server. A cached response is "fresh" if its age does
not exceed its freshness lifetime. Age values are calculated as
specified in section 13.2.3.
Age = "Age" ":" age-value
age-value = delta-seconds
Age values are non-negative decimal integers, representing time in
seconds.
If a cache receives a value larger than the largest positive integer
it can represent, or if any of its age calculations overflows, it
MUST transmit an Age header with a value of 2147483648 (2^31).
HTTP/1.1 caches MUST send an Age header in every response. Caches
SHOULD use an arithmetic type of at least 31 bits of range.
14.7 Allow
The Allow entity-header field lists the set of methods supported by
the resource identified by the Request-URI. The purpose of this field
is strictly to inform the recipient of valid methods associated with
the resource. An Allow header field MUST be present in a 405 (Method
Not Allowed) response.
Allow = "Allow" ":" 1#method
Example of use:
Allow: GET, HEAD, PUT
This field cannot prevent a client from trying other methods.
However, the indications given by the Allow header field value SHOULD
be followed. The actual set of allowed methods is defined by the
origin server at the time of each request.
The Allow header field MAY be provided with a PUT request to
recommend the methods to be supported by the new or modified
resource. The server is not required to support these methods and
SHOULD include an Allow header in the response giving the actual
supported methods.
A proxy MUST NOT modify the Allow header field even if it does not
understand all the methods specified, since the user agent MAY have
other means of communicating with the origin server.
The Allow header field does not indicate what methods are implemented
at the server level. Servers MAY use the Public response-header field
(section 14.35) to describe what methods are implemented on the
server as a whole.
14.8 Authorization
A user agent that wishes to authenticate itself with a server--
usually, but not necessarily, after receiving a 401 response--MAY do
so by including an Authorization request-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 11. If a request
is authenticated and a realm specified, the same credentials SHOULD
be valid for all other requests within this realm.
When a shared cache (see section 13.7) receives a request containing
an Authorization field, it MUST NOT return the corresponding response
as a reply to any other request, unless one of the following specific
exceptions holds:
1. If the response includes the "proxy-revalidate" Cache-Control
directive, the cache MAY use that response in replying to a
subsequent request, but a proxy cache MUST first revalidate it with
the origin server, using the request-headers from the new request
to allow the origin server to authenticate the new request.
2. If the response includes the "must-revalidate" Cache-Control
directive, the cache MAY use that response in replying to a
subsequent request, but all caches MUST first revalidate it with
the origin server, using the request-headers from the new request
to allow the origin server to authenticate the new request.
3. If the response includes the "public" Cache-Control directive, it
may be returned in reply to any subsequent request.
14.9 Cache-Control
The Cache-Control general-header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the
request/response chain. The directives specify behavior intended to
prevent caches from adversely interfering with the request or
response. These directives typically override the default caching
algorithms. Cache directives are unidirectional in that the presence
of a directive in a request does not imply that the same directive
should be given in the response.
Note that HTTP/1.0 caches may not implement Cache-Control and may
only implement Pragma: no-cache (see section 14.32).
Cache directives must be passed through by a proxy or gateway
application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a cache-
directive for a specific cache.
Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive
| cache-response-directive
cache-request-directive =
"no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "max-age" "=" delta-seconds
| "max-stale" [ "=" delta-seconds ]
| "min-fresh" "=" delta-seconds
| "only-if-cached"
| cache-extension
cache-response-directive =
"public"
| "private" [ "=" <"> 1#field-name <"> ]
| "no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "no-transform"
| "must-revalidate"
| "proxy-revalidate"
| "max-age" "=" delta-seconds
| cache-extension
cache-extension = token [ "=" ( token | quoted-string ) ]
When a directive appears without any 1#field-name parameter, the
directive applies to the entire request or response. When such a
directive appears with a 1#field-name parameter, it applies only to
the named field or fields, and not to the rest of the request or
response. This mechanism supports extensibility; implementations of
future versions of the HTTP protocol may apply these directives to
header fields not defined in HTTP/1.1.
The cache-control directives can be broken down into these general
categories:
o Restrictions on what is cachable; these may only be imposed by the
origin server.
o Restrictions on what may be stored by a cache; these may be imposed
by either the origin server or the user agent.
o Modifications of the basic expiration mechanism; these may be
imposed by either the origin server or the user agent.
o Controls over cache revalidation and reload; these may only be
imposed by a user agent.
o Control over transformation of entities.
o Extensions to the caching system.
14.9.1 What is Cachable
By default, a response is cachable if the requirements of the request
method, request header fields, and the response status indicate that
it is cachable. Section 13.4 summarizes these defaults for
cachability. The following Cache-Control response directives allow an
origin server to override the default cachability of a response:
public
Indicates that the response is cachable by any cache, even if it
would normally be non-cachable or cachable only within a non-shared
cache. (See also Authorization, section 14.8, for additional
details.)
private
Indicates that all or part of the response message is intended for a
single user and MUST NOT be cached by a shared cache. This allows an
origin server to state that the specified parts of the response are
intended for only one user and are not a valid response for requests
by other users. A private (non-shared) cache may cache the response.
Note: This usage of the word private only controls where the
response may be cached, and cannot ensure the privacy of the
message content.
no-cache
Indicates that all or part of the response message MUST NOT be cached
anywhere. This allows an origin server to prevent caching even by
caches that have been configured to return stale responses to client
requests.
Note: Most HTTP/1.0 caches will not recognize or obey this
directive.
14.9.2 What May be Stored by Caches
The purpose of the no-store directive is to prevent the inadvertent
release or retention of sensitive information (for example, on backup
tapes). The no-store directive applies to the entire message, and may
be sent either in a response or in a request. If sent in a request, a
cache MUST NOT store any part of either this request or any response
to it. If sent in a response, a cache MUST NOT store any part of
either this response or the request that elicited it. This directive
applies to both non-shared and shared caches. "MUST NOT store" in
this context means that the cache MUST NOT intentionally store the
information in non-volatile storage, and MUST make a best-effort
attempt to remove the information from volatile storage as promptly
as possible after forwarding it.
Even when this directive is associated with a response, users may
explicitly store such a response outside of the caching system (e.g.,
with a "Save As" dialog). History buffers may store such responses as
part of their normal operation.
The purpose of this directive is to meet the stated requirements of
certain users and service authors who are concerned about accidental
releases of information via unanticipated accesses to cache data
structures. While the use of this directive may improve privacy in
some cases, we caution that it is NOT in any way a reliable or
sufficient mechanism for ensuring privacy. In particular, malicious
or compromised caches may not recognize or obey this directive; and
communications networks may be vulnerable to eavesdropping.
14.9.3 Modifications of the Basic Expiration Mechanism
The expiration time of an entity may be specified by the origin
server using the Expires header (see section 14.21). Alternatively,
it may be specified using the max-age directive in a response.
If a response includes both an Expires header and a max-age
directive, the max-age directive overrides the Expires header, even
if the Expires header is more restrictive. This rule allows an origin
server to provide, for a given response, a longer expiration time to
an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be
useful if certain HTTP/1.0 caches improperly calculate ages or
expiration times, perhaps due to desynchronized clocks.
Note: most older caches, not compliant with this specification, do
not implement any Cache-Control directives. An origin server
wishing to use a Cache-Control directive that restricts, but does
not prevent, caching by an HTTP/1.1-compliant cache may exploit the
requirement that the max-age directive overrides the Expires
header, and the fact that non-HTTP/1.1-compliant caches do not
observe the max-age directive.
Other directives allow an user agent to modify the basic expiration
mechanism. These directives may be specified on a request:
max-age
Indicates that the client is willing to accept a response whose age
is no greater than the specified time in seconds. Unless max-stale
directive is also included, the client is not willing to accept a
stale response.
min-fresh
Indicates that the client is willing to accept a response whose
freshness lifetime is no less than its current age plus the
specified time in seconds. That is, the client wants a response
that will still be fresh for at least the specified number of
seconds.
max-stale
Indicates that the client is willing to accept a response that has
exceeded its expiration time. If max-stale is assigned a value,
then the client is willing to accept a response that has exceeded
its expiration time by no more than the specified number of
seconds. If no value is assigned to max-stale, then the client is
willing to accept a stale response of any age.
If a cache returns a stale response, either because of a max-stale
directive on a request, or because the cache is configured to
override the expiration time of a response, the cache MUST attach a
Warning header to the stale response, using Warning 10 (Response is
stale).
14.9.4 Cache Revalidation and Reload Controls
Sometimes an user agent may want or need to insist that a cache
revalidate its cache entry with the origin server (and not just with
the next cache along the path to the origin server), or to reload its
cache entry from the origin server. End-to-end revalidation may be
necessary if either the cache or the origin server has overestimated
the expiration time of the cached response. End-to-end reload may be
necessary if the cache entry has become corrupted for some reason.
End-to-end revalidation may be requested either when the client does
not have its own local cached copy, in which case we call it
"unspecified end-to-end revalidation", or when the client does have a
local cached copy, in which case we call it "specific end-to-end
revalidation."
The client can specify these three kinds of action using Cache-
Control request directives:
End-to-end reload
The request includes a "no-cache" Cache-Control directive or, for
compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field
names may be included with the no-cache directive in a request. The
server MUST NOT use a cached copy when responding to such a
request.
Specific end-to-end revalidation
The request includes a "max-age=0" Cache-Control directive, which
forces each cache along the path to the origin server to revalidate
its own entry, if any, with the next cache or server. The initial
request includes a cache-validating conditional with the client's
current validator.
Unspecified end-to-end revalidation
The request includes "max-age=0" Cache-Control directive, which
forces each cache along the path to the origin server to revalidate
its own entry, if any, with the next cache or server. The initial
request does not include a cache-validating conditional; the first
cache along the path (if any) that holds a cache entry for this
resource includes a cache-validating conditional with its current
validator.
When an intermediate cache is forced, by means of a max-age=0
directive, to revalidate its own cache entry, and the client has
supplied its own validator in the request, the supplied validator may
differ from the validator currently stored with the cache entry. In
this case, the cache may use either validator in making its own
request without affecting semantic transparency.
However, the choice of validator may affect performance. The best
approach is for the intermediate cache to use its own validator when
making its request. If the server replies with 304 (Not Modified),
then the cache should return its now validated copy to the client
with a 200 (OK) response. If the server replies with a new entity and
cache validator, however, the intermediate cache should compare the
returned validator with the one provided in the client's request,
using the strong comparison function. If the client's validator is
equal to the origin server's, then the intermediate cache simply
returns 304 (Not Modified). Otherwise, it returns the new entity with
a 200 (OK) response.
If a request includes the no-cache directive, it should not include
min-fresh, max-stale, or max-age.
In some cases, such as times of extremely poor network connectivity,
a client may want a cache to return only those responses that it
currently has stored, and not to reload or revalidate with the origin
server. To do this, the client may include the only-if-cached
directive in a request. If it receives this directive, a cache SHOULD
either respond using a cached entry that is consistent with the other
constraints of the request, or respond with a 504 (Gateway Timeout)
status. However, if a group of caches is being operated as a unified
system with good internal connectivity, such a request MAY be
forwarded within that group of caches.
Because a cache may be configured to ignore a server's specified
expiration time, and because a client request may include a max-stale
directive (which has a similar effect), the protocol also includes a
mechanism for the origin server to require revalidation of a cache
entry on any subsequent use. When the must-revalidate directive is
present in a response received by a cache, that cache MUST NOT use
the entry after it becomes stale to respond to a subsequent request
without first revalidating it with the origin server. (I.e., the
cache must do an end-to-end revalidation every time, if, based solely
on the origin server's Expires or max-age value, the cached response
is stale.)
The must-revalidate directive is necessary to support reliable
operation for certain protocol features. In all circumstances an
HTTP/1.1 cache MUST obey the must-revalidate directive; in
particular, if the cache cannot reach the origin server for any
reason, it MUST generate a 504 (Gateway Timeout) response.
Servers should send the must-revalidate directive if and only if
failure to revalidate a request on the entity could result in
incorrect operation, such as a silently unexecuted financial
transaction. Recipients MUST NOT take any automated action that
violates this directive, and MUST NOT automatically provide an
unvalidated copy of the entity if revalidation fails.
Although this is not recommended, user agents operating under severe
connectivity constraints may violate this directive but, if so, MUST
explicitly warn the user that an unvalidated response has been
provided. The warning MUST be provided on each unvalidated access,
and SHOULD require explicit user confirmation.
The proxy-revalidate directive has the same meaning as the must-
revalidate directive, except that it does not apply to non-shared
user agent caches. It can be used on a response to an authenticated
request to permit the user's cache to store and later return the
response without needing to revalidate it (since it has already been
authenticated once by that user), while still requiring proxies that
service many users to revalidate each time (in order to make sure
that each user has been authenticated). Note that such authenticated
responses also need the public cache control directive in order to
allow them to be cached at all.
14.9.5 No-Transform Directive
Implementers of intermediate caches (proxies) have found it useful to
convert the media type of certain entity bodies. A proxy might, for
example, convert between image formats in order to save cache space
or to reduce the amount of traffic on a slow link. HTTP has to date
been silent on these transformations.
Serious operational problems have already occurred, however, when
these transformations have been applied to entity bodies intended for
certain kinds of applications. For example, applications for medical
imaging, scientific data analysis and those using end-to-end
authentication, all depend on receiving an entity body that is bit
for bit identical to the original entity-body.
Therefore, if a response includes the no-transform directive, an
intermediate cache or proxy MUST NOT change those headers that are
listed in section 13.5.2 as being subject to the no-transform
directive. This implies that the cache or proxy must not change any
aspect of the entity-body that is specified by these headers.
14.9.6 Cache Control Extensions
The Cache-Control header field can be extended through the use of one
or more cache-extension tokens, each with an optional assigned value.
Informational extensions (those which do not require a change in
cache behavior) may be added without changing the semantics of other
directives. Behavioral extensions are designed to work by acting as
modifiers to the existing base of cache directives. Both the new
directive and the standard directive are supplied, such that
applications which do not understand the new directive will default
to the behavior specified by the standard directive, and those that
understand the new directive will recognize it as modifying the
requirements associated with the standard directive. In this way,
extensions to the Cache-Control directives can be made without
requiring changes to the base protocol.
This extension mechanism depends on a HTTP cache obeying all of the
cache-control directives defined for its native HTTP-version, obeying
certain extensions, and ignoring all directives that it does not
understand.
For example, consider a hypothetical new response directive called
"community" which acts as a modifier to the "private" directive. We
define this new directive to mean that, in addition to any non-shared
cache, any cache which is shared only by members of the community
named within its value may cache the response. An origin server
wishing to allow the "UCI" community to use an otherwise private
response in their shared cache(s) may do so by including
Cache-Control: private, community="UCI"
A cache seeing this header field will act correctly even if the cache
does not understand the "community" cache-extension, since it will
also see and understand the "private" directive and thus default to
the safe behavior.
Unrecognized cache-directives MUST be ignored; it is assumed that any
cache-directive likely to be unrecognized by an HTTP/1.1 cache will
be combined with standard directives (or the response's default
cachability) such that the cache behavior will remain minimally
correct even if the cache does not understand the extension(s).
14.10 Connection
The Connection general-header field allows the sender to specify
options that are desired for that particular connection and MUST NOT
be communicated by proxies over further connections.
The Connection header has the following grammar:
Connection-header = "Connection" ":" 1#(connection-token)
connection-token = token
HTTP/1.1 proxies MUST parse the Connection header field before a
message is forwarded and, for each connection-token in this field,
remove any header field(s) from the message with the same name as the
connection-token. Connection options are signaled by the presence of
a connection-token in the Connection header field, not by any
corresponding additional header field(s), since the additional header
field may not be sent if there are no parameters associated with that
connection option. HTTP/1.1 defines the "close" connection option
for the sender to signal that the connection will be closed after
completion of the response. For example,
Connection: close
in either the request or the response header fields indicates that
the connection should not be considered `persistent' (section 8.1)
after the current request/response is complete.
HTTP/1.1 applications that do not support persistent connections MUST
include the "close" connection option in every message.
14.11 Content-Base
The Content-Base entity-header field may be used to specify the base
URI for resolving relative URLs within the entity. This header field
is described as Base in RFC 1808, which is expected to be revised.
Content-Base = "Content-Base" ":" absoluteURI
If no Content-Base field is present, the base URI of an entity is
defined either by its Content-Location (if that Content-Location URI
is an absolute URI) or the URI used to initiate the request, in that
order of precedence. Note, however, that the base URI of the contents
within the entity-body may be redefined within that entity-body.
14.12 Content-Encoding
The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional content
codings have been applied to the entity-body, and thus what decoding
mechanisms MUST be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing
the identity of its underlying media type.
Content-Encoding = "Content-Encoding" ":" 1#content-coding
Content codings are defined in section 3.5. An example of its use is
Content-Encoding: gzip
The Content-Encoding is a characteristic of the entity identified by
the Request-URI. Typically, the entity-body is stored with this
encoding and is only decoded before rendering or analogous usage.
If multiple encodings have been applied to an entity, the content
codings MUST be listed in the order in which they were applied.
Additional information about the encoding parameters MAY be provided
by other entity-header fields not defined by this specification.
14.13 Content-Language
The Content-Language entity-header field describes the natural
language(s) of the intended audience for the enclosed entity. Note
that this may not be equivalent to all the languages used within the
entity-body.
Content-Language = "Content-Language" ":" 1#language-tag
Language tags are defined in section 3.10. The primary purpose of
Content-Language is to allow a user to identify and differentiate
entities according to the user's own preferred language. Thus, if the
body content is intended only for a Danish-literate audience, the
appropriate field is
Content-Language: da
If no Content-Language is specified, the default is that the content
is intended for all language audiences. This may mean that the sender
does not consider it to be specific to any natural language, or that
the sender does not know for which language it is intended.
Multiple languages MAY be listed for content that is intended for
multiple audiences. For example, a rendition of the "Treaty of
Waitangi," presented simultaneously in the original Maori and English
versions, would call for
Content-Language: mi, en
However, just because multiple languages are present within an entity
does not mean that it is intended for multiple linguistic audiences.
An example would be a beginner's language primer, such as "A First
Lesson in Latin," which is clearly intended to be used by an
English-literate audience. In this case, the Content-Language should
only include "en".
Content-Language may be applied to any media type -- it is not
limited to textual documents.
14.14 Content-Length
The Content-Length entity-header field indicates the size of the
message-body, in decimal number of octets, sent to the recipient or,
in the case of the HEAD method, the size of the entity-body that
would have been sent had the request been a GET.
Content-Length = "Content-Length" ":" 1*DIGIT
An example is
Content-Length: 3495
Applications SHOULD use this field to indicate the size of the
message-body to be transferred, regardless of the media type of the
entity. It must be possible for the recipient to reliably determine
the end of HTTP/1.1 requests containing an entity-body, e.g., because
the request has a valid Content-Length field, uses Transfer-Encoding:
chunked or a multipart body.
Any Content-Length greater than or equal to zero is a valid value.
Section 4.4 describes how to determine the length of a message-body
if a Content-Length is not given.
Note: The meaning of this field is significantly different from the
corresponding definition in MIME, where it is an optional field
used within the "message/external-body" content-type. In HTTP, it
SHOULD be sent whenever the message's length can be determined
prior to being transferred.
14.15 Content-Location
The Content-Location entity-header field may be used to supply the
resource location for the entity enclosed in the message. In the case
where a resource has multiple entities associated with it, and those
entities actually have separate locations by which they might be
individually accessed, the server should provide a Content-Location
for the particular variant which is returned. In addition, a server
SHOULD provide a Content-Location for the resource corresponding to
the response entity.
Content-Location = "Content-Location" ":"
( absoluteURI | relativeURI )
If no Content-Base header field is present, the value of Content-
Location also defines the base URL for the entity (see section
14.11).
The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource
corresponding to this particular entity at the time of the request.
Future requests MAY use the Content-Location URI if the desire is to
identify the source of that particular entity.
A cache cannot assume that an entity with a Content-Location
different from the URI used to retrieve it can be used to respond to
later requests on that Content-Location URI. However, the Content-
Location can be used to differentiate between multiple entities
retrieved from a single requested resource, as described in section
13.6.
If the Content-Location is a relative URI, the URI is interpreted
relative to any Content-Base URI provided in the response. If no
Content-Base is provided, the relative URI is interpreted relative to
the Request-URI.
14.16 Content-MD5
The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
an MD5 digest of the entity-body for the purpose of providing an
end-to-end message integrity check (MIC) of the entity-body. (Note: a
MIC is good for detecting accidental modification of the entity-body
in transit, but is not proof against malicious attacks.)
Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
The Content-MD5 header field may be generated by an origin server to
function as an integrity check of the entity-body. Only origin
servers may generate the Content-MD5 header field; proxies and
gateways MUST NOT generate it, as this would defeat its value as an
end-to-end integrity check. Any recipient of the entity-body,
including gateways and proxies, MAY check that the digest value in
this header field matches that of the entity-body as received.
The MD5 digest is computed based on the content of the entity-body,
including any Content-Encoding that has been applied, but not
including any Transfer-Encoding that may have been applied to the
message-body. If the message is received with a Transfer-Encoding,
that encoding must be removed prior to checking the Content-MD5 value
against the received entity.
This has the result that the digest is computed on the octets of the
entity-body exactly as, and in the order that, they would be sent if
no Transfer-Encoding were being applied.
HTTP extends RFC 1864 to permit the digest to be computed for MIME
composite media-types (e.g., multipart/* and message/rfc822), but
this does not change how the digest is computed as defined in the
preceding paragraph.
Note: There are several consequences of this. The entity-body for
composite types may contain many body-parts, each with its own MIME
and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
and Content-Encoding headers). If a body-part has a Content-
Transfer-Encoding or Content-Encoding header, it is assumed that
the content of the body-part has had the encoding applied, and the
body-part is included in the Content-MD5 digest as is -- i.e.,
after the application. The Transfer-Encoding header field is not
allowed within body-parts.
Note: while the definition of Content-MD5 is exactly the same for
HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
in which the application of Content-MD5 to HTTP entity-bodies
differs from its application to MIME entity-bodies. One is that
HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does
use Transfer-Encoding and Content-Encoding. Another is that HTTP
more frequently uses binary content types than MIME, so it is worth
noting that, in such cases, the byte order used to compute the
digest is the transmission byte order defined for the type. Lastly,
HTTP allows transmission of text types with any of several line
break conventions and not just the canonical form using CRLF.
Conversion of all line breaks to CRLF should not be done before
computing or checking the digest: the line break convention used in
the text actually transmitted should be left unaltered when
computing the digest.
14.17 Content-Range
The Content-Range entity-header is sent with a partial entity-body to
specify where in the full entity-body the partial body should be
inserted. It also indicates the total size of the full entity-body.
When a server returns a partial response to a client, it must
describe both the extent of the range covered by the response, and
the length of the entire entity-body.
Content-Range = "Content-Range" ":" content-range-spec
content-range-spec = byte-content-range-spec
byte-content-range-spec = bytes-unit SP first-byte-pos "-"
last-byte-pos "/" entity-length
entity-length = 1*DIGIT
Unlike byte-ranges-specifier values, a byte-content-range-spec may
only specify one range, and must contain absolute byte positions for
both the first and last byte of the range.
A byte-content-range-spec whose last-byte-pos value is less than its
first-byte-pos value, or whose entity-length value is less than or
equal to its last-byte-pos value, is invalid. The recipient of an
invalid byte-content-range-spec MUST ignore it and any content
transferred along with it.
Examples of byte-content-range-spec values, assuming that the entity
contains a total of 1234 bytes:
o The first 500 bytes:
bytes 0-499/1234
o The second 500 bytes:
bytes 500-999/1234
o All except for the first 500 bytes:
bytes 500-1233/1234
o The last 500 bytes:
bytes 734-1233/1234
When an HTTP message includes the content of a single range (for
example, a response to a request for a single range, or to a request
for a set of ranges that overlap without any holes), this content is
transmitted with a Content-Range header, and a Content-Length header
showing the number of bytes actually transferred. For example,
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
When an HTTP message includes the content of multiple ranges (for
example, a response to a request for multiple non-overlapping
ranges), these are transmitted as a multipart MIME message. The
multipart MIME content-type used for this purpose is defined in this
specification to be "multipart/byteranges". See appendix 19.2 for its
definition.
A client that cannot decode a MIME multipart/byteranges message
should not ask for multiple byte-ranges in a single request.
When a client requests multiple byte-ranges in one request, the
server SHOULD return them in the order that they appeared in the
request.
If the server ignores a byte-range-spec because it is invalid, the
server should treat the request as if the invalid Range header field
did not exist. (Normally, this means return a 200 response containing
the full entity). The reason is that the only time a client will make
such an invalid request is when the entity is smaller than the entity
retrieved by a prior request.
14.18 Content-Type
The Content-Type entity-header field indicates the media type of the
entity-body sent to the recipient or, in the case of the HEAD method,
the media type that would have been sent had the request been a GET.
Content-Type = "Content-Type" ":" media-type
Media types are defined in section 3.7. An example of the field is
Content-Type: text/html; charset=ISO-8859-4
Further discussion of methods for identifying the media type of an
entity is provided in section 7.2.1.
14.19 Date
The Date general-header field represents the date and time at which
the message was originated, having the same semantics as orig-date in
RFC 822. The field value is an HTTP-date, as described in section
3.3.1.
Date = "Date" ":" HTTP-date
An example is
Date: Tue, 15 Nov 1994 08:12:31 GMT
If a message is received via direct connection with the user agent
(in the case of requests) or the origin server (in the case of
responses), then the date can be assumed to be the current date at
the receiving end. However, since the date--as it is believed by the
origin--is important for evaluating cached responses, origin servers
MUST include a Date header field in all responses. Clients SHOULD
only send a Date header field in messages that include an entity-
body, as in the case of the PUT and POST requests, and even then it
is optional. A received message which does not have a Date header
field SHOULD be assigned one by the recipient if the message will be
cached by that recipient or gatewayed via a protocol which requires a
Date.
In theory, the date SHOULD represent the moment just before the
entity is generated. In practice, the date can be generated at any
time during the message origination without affecting its semantic
value.
The format of the Date is an absolute date and time as defined by
HTTP-date in section 3.3; it MUST be sent in RFC1123 [8]-date format.
14.20 ETag
The ETag entity-header field defines the entity tag for the
associated entity. The headers used with entity tags are described in
sections 14.20, 14.25, 14.26 and 14.43. The entity tag may be used
for comparison with other entities from the same resource (see
section 13.3.2).
ETag = "ETag" ":" entity-tag
Examples:
ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""
14.21 Expires
The Expires entity-header field gives the date/time after which the
response should be considered stale. A stale cache entry may not
normally be returned by a cache (either a proxy cache or an user
agent cache) unless it is first validated with the origin server (or
with an intermediate cache that has a fresh copy of the entity). See
section 13.2 for further discussion of the expiration model.
The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that
time.
The format is an absolute date and time as defined by HTTP-date in
section 3.3; it MUST be in RFC1123-date format:
Expires = "Expires" ":" HTTP-date
An example of its use is
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Note: if a response includes a Cache-Control field with the max-age
directive, that directive overrides the Expires field.
HTTP/1.1 clients and caches MUST treat other invalid date formats,
especially including the value "0", as in the past (i.e., "already
expired").
To mark a response as "already expired," an origin server should use
an Expires date that is equal to the Date header value. (See the
rules for expiration calculations in section 13.2.4.)
To mark a response as "never expires," an origin server should use an
Expires date approximately one year from the time the response is
sent. HTTP/1.1 servers should not send Expires dates more than one
year in the future.
The presence of an Expires header field with a date value of some
time in the future on an response that otherwise would by default be
non-cacheable indicates that the response is cachable, unless
indicated otherwise by a Cache-Control header field (section 14.9).
14.22 From
The From request-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 mailbox
in RFC 822 (as updated by RFC 1123 ):
From = "From" ":" mailbox
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 MAY be separate from the
Internet host which issued the request. For example, when a request
is passed through a proxy the original issuer's address SHOULD be
used.
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.
14.23 Host
The Host request-header field specifies the Internet host and port
number of the resource being requested, as obtained from the original
URL given by the user or referring resource (generally an HTTP URL,
as described in section 3.2.2). The Host field value MUST represent
the network location of the origin server or gateway given by the
original URL. This allows the origin server or gateway to
differentiate between internally-ambiguous URLs, such as the root "/"
URL of a server for multiple host names on a single IP address.
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
A "host" without any trailing port information implies the default
port for the service requested (e.g., "80" for an HTTP URL). For
example, a request on the origin server for
<http://www.w3.org/pub/WWW/> MUST include:
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
A client MUST include a Host header field in all HTTP/1.1 request
messages on the Internet (i.e., on any message corresponding to a
request for a URL which includes an Internet host address for the
service being requested). If the Host field is not already present,
an HTTP/1.1 proxy MUST add a Host field to the request message prior
to forwarding it on the Internet. All Internet-based HTTP/1.1 servers
MUST respond with a 400 status code to any HTTP/1.1 request message
which lacks a Host header field.
See sections 5.2 and 19.5.1 for other requirements relating to Host.
14.24 If-Modified-Since
The If-Modified-Since request-header field is used with the GET
method to make it conditional: if the requested variant has not been
modified since the time specified in this field, an entity will not
be returned from the server; instead, a 304 (not modified) response
will be returned without any message-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
A GET method with an If-Modified-Since header and no Range header
requests that the identified entity be transferred only if it has
been modified since the date given by the If-Modified-Since header.
The algorithm for determining this includes the following cases:
a)If the request would normally result in anything other than a 200
(OK) status, or if the passed If-Modified-Since date is invalid, the
response is exactly the same as for a normal GET. A date which is
later than the server's current time is invalid.
b)If the variant has been modified since the If-Modified-Since date,
the response is exactly the same as for a normal GET.
c)If the variant has not been modified since a valid If-Modified-Since
date, the server MUST return a 304 (Not Modified) response.
The purpose of this feature is to allow efficient updates of cached
information with a minimum amount of transaction overhead.
Note that the Range request-header field modifies the meaning of
If-Modified-Since; see section 14.36 for full details.
Note that If-Modified-Since times are interpreted by the server,
whose clock may not be synchronized with the client.
Note that if a client uses an arbitrary date in the If-Modified-Since
header instead of a date taken from the Last-Modified header for the
same request, the client should be aware of the fact that this date
is interpreted in the server's understanding of time. The client
should consider unsynchronized clocks and rounding problems due to
the different encodings of time between the client and server. This
includes the possibility of race conditions if the document has
changed between the time it was first requested and the If-Modified-
Since date of a subsequent request, and the possibility of clock-
skew-related problems if the If-Modified-Since date is derived from
the client's clock without correction to the server's clock.
Corrections for different time bases between client and server are at
best approximate due to network latency.
14.25 If-Match
The If-Match request-header field is used with a method to make it
conditional. A client that has one or more entities previously
obtained from the resource can verify that one of those entities is
current by including a list of their associated entity tags in the
If-Match header field. The purpose of this feature is to allow
efficient updates of cached information with a minimum amount of
transaction overhead. It is also used, on updating requests, to
prevent inadvertent modification of the wrong version of a resource.
As a special case, the value "*" matches any current entity of the
resource.
If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
If any of the entity tags match the entity tag of the entity that
would have been returned in the response to a similar GET request
(without the If-Match header) on that resource, or if "*" is given
and any current entity exists for that resource, then the server MAY
perform the requested method as if the If-Match header field did not
exist.
A server MUST use the strong comparison function (see section 3.11)
to compare the entity tags in If-Match.
If none of the entity tags match, or if "*" is given and no current
entity exists, the server MUST NOT perform the requested method, and
MUST return a 412 (Precondition Failed) response. This behavior is
most useful when the client wants to prevent an updating method, such
as PUT, from modifying a resource that has changed since the client
last retrieved it.
If the request would, without the If-Match header field, result in
anything other than a 2xx status, then the If-Match header MUST be
ignored.
The meaning of "If-Match: *" is that the method SHOULD be performed
if the representation selected by the origin server (or by a cache,
possibly using the Vary mechanism, see section 14.43) exists, and
MUST NOT be performed if the representation does not exist.
A request intended to update a resource (e.g., a PUT) MAY include an
If-Match header field to signal that the request method MUST NOT be
applied if the entity corresponding to the If-Match value (a single
entity tag) is no longer a representation of that resource. This
allows the user to indicate that they do not wish the request to be
successful if the resource has been changed without their knowledge.
Examples:
If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *
14.26 If-None-Match
The If-None-Match request-header field is used with a method to make
it conditional. A client that has one or more entities previously
obtained from the resource can verify that none of those entities is
current by including a list of their associated entity tags in the
If-None-Match header field. The purpose of this feature is to allow
efficient updates of cached information with a minimum amount of
transaction overhead. It is also used, on updating requests, to
prevent inadvertent modification of a resource which was not known to
exist.
As a special case, the value "*" matches any current entity of the
resource.
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
If any of the entity tags match the entity tag of the entity that
would have been returned in the response to a similar GET request
(without the If-None-Match header) on that resource, or if "*" is
given and any current entity exists for that resource, then the
server MUST NOT perform the requested method. Instead, if the request
method was GET or HEAD, the server SHOULD respond with a 304 (Not
Modified) response, including the cache-related entity-header fields
(particularly ETag) of one of the entities that matched. For all
other request methods, the server MUST respond with a status of 412
(Precondition Failed).
See section 13.3.3 for rules on how to determine if two entity tags
match. The weak comparison function can only be used with GET or HEAD
requests.
If none of the entity tags match, or if "*" is given and no current
entity exists, then the server MAY perform the requested method as if
the If-None-Match header field did not exist.
If the request would, without the If-None-Match header field, result
in anything other than a 2xx status, then the If-None-Match header
MUST be ignored.
The meaning of "If-None-Match: *" is that the method MUST NOT be
performed if the representation selected by the origin server (or by
a cache, possibly using the Vary mechanism, see section 14.43)
exists, and SHOULD be performed if the representation does not exist.
This feature may be useful in preventing races between PUT
operations.
Examples:
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *
14.27 If-Range
If a client has a partial copy of an entity in its cache, and wishes
to have an up-to-date copy of the entire entity in its cache, it
could use the Range request-header with a conditional GET (using
either or both of If-Unmodified-Since and If-Match.) However, if the
condition fails because the entity has been modified, the client
would then have to make a second request to obtain the entire current
entity-body.
The If-Range header allows a client to "short-circuit" the second
request. Informally, its meaning is `if the entity is unchanged, send
me the part(s) that I am missing; otherwise, send me the entire new
entity.'
If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
If the client has no entity tag for an entity, but does have a Last-
Modified date, it may use that date in a If-Range header. (The server
can distinguish between a valid HTTP-date and any form of entity-tag
by examining no more than two characters.) The If-Range header should
only be used together with a Range header, and must be ignored if the
request does not include a Range header, or if the server does not
support the sub-range operation.
If the entity tag given in the If-Range header matches the current
entity tag for the entity, then the server should provide the
specified sub-range of the entity using a 206 (Partial content)
response. If the entity tag does not match, then the server should
return the entire entity using a 200 (OK) response.
14.28 If-Unmodified-Since
The If-Unmodified-Since request-header field is used with a method to
make it conditional. If the requested resource has not been modified
since the time specified in this field, the server should perform the
requested operation as if the If-Unmodified-Since header were not
present.
If the requested variant has been modified since the specified time,
the server MUST NOT perform the requested operation, and MUST return
a 412 (Precondition Failed).
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
An example of the field is:
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If the request normally (i.e., without the If-Unmodified-Since
header) would result in anything other than a 2xx status, the If-
Unmodified-Since header should be ignored.
If the specified date is invalid, the header is ignored.
14.29 Last-Modified
The Last-Modified entity-header field indicates the date and time at
which the origin server believes the variant was last modified.
Last-Modified = "Last-Modified" ":" HTTP-date
An example of its use is
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
The exact meaning of this header field depends on the implementation
of the origin server and the nature of the original resource. For
files, it may be just the file system last-modified time. For
entities with dynamically included parts, it may be the most recent
of the set of last-modify times for its component parts. For database
gateways, it may be the last-update time stamp of the record. For
virtual objects, it may be the last time the internal state changed.
An origin server MUST NOT send a Last-Modified date which is later
than the server's time of message origination. In such cases, where
the resource's last modification would indicate some time in the
future, the server MUST replace that date with the message
origination date.
An origin server should obtain the Last-Modified value of the entity
as close as possible to the time that it generates the Date value of
its response. This allows a recipient to make an accurate assessment
of the entity's modification time, especially if the entity changes
near the time that the response is generated.
HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
14.30 Location
The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the
request or identification of a new resource. For 201 (Created)
responses, the Location is that of the new resource which was created
by the request. For 3xx responses, the location SHOULD indicate the
server's preferred URL for automatic redirection to the resource. The
field value consists of a single absolute URL.
Location = "Location" ":" absoluteURI
An example is
Location: http://www.w3.org/pub/WWW/People.html
Note: The Content-Location header field (section 14.15) differs
from Location in that the Content-Location identifies the original
location of the entity enclosed in the request. It is therefore
possible for a response to contain header fields for both Location
and Content-Location. Also see section 13.10 for cache requirements
of some methods.
14.31 Max-Forwards
The Max-Forwards request-header field may be used with the TRACE
method (section 14.31) to limit the number of proxies or gateways
that can forward the request to the next inbound server. This can be
useful when the client is attempting to trace a request chain which
appears to be failing or looping in mid-chain.
Max-Forwards = "Max-Forwards" ":" 1*DIGIT
The Max-Forwards value is a decimal integer indicating the remaining
number of times this request message may be forwarded.
Each proxy or gateway recipient of a TRACE request containing a Max-
Forwards header field SHOULD check and update its value prior to
forwarding the request. If the received value is zero (0), the
recipient SHOULD NOT forward the request; instead, it SHOULD respond
as the final recipient with a 200 (OK) response containing the
received request message as the response entity-body (as described in
section 9.8). If the received Max-Forwards value is greater than
zero, then the forwarded message SHOULD contain an updated Max-
Forwards field with a value decremented by one (1).
The Max-Forwards header field SHOULD be ignored for all other methods
defined by this specification and for any extension methods for which
it is not explicitly referred to as part of that method definition.
14.32 Pragma
The Pragma general-header field is used to include implementation-
specific directives that may apply to any recipient along the
request/response chain. All pragma directives specify optional
behavior from the viewpoint of the protocol; however, some systems
MAY require that behavior be consistent with the directives.
Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" ( token | quoted-string ) ]
When the no-cache directive is present in a request message, an
application SHOULD forward the request toward the origin server even
if it has a cached copy of what is being requested. This pragma
directive has the same semantics as the no-cache cache-directive (see
section 14.9) and is defined here for backwards compatibility with
HTTP/1.0. Clients SHOULD include both header fields when a no-cache
request is sent to a server not known to be HTTP/1.1 compliant.
Pragma directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a pragma for a
specific recipient; however, any pragma directive not relevant to a
recipient SHOULD be ignored by that recipient.
HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1
caches SHOULD treat "Pragma: no-cache" as if the client had sent
"Cache-Control: no-cache". No new Pragma directives will be defined
in HTTP.
14.33 Proxy-Authenticate
The Proxy-Authenticate response-header field MUST be included as part
of a 407 (Proxy Authentication Required) response. The field value
consists of a challenge that indicates the authentication scheme and
parameters applicable to the proxy for this Request-URI.
Proxy-Authenticate = "Proxy-Authenticate" ":" challenge
The HTTP access authentication process is described in section 11.
Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
only to the current connection and SHOULD NOT be passed on to
downstream clients. However, an intermediate proxy may need to obtain
its own credentials by requesting them from the downstream client,
which in some circumstances will appear as if the proxy is forwarding
the Proxy-Authenticate header field.
14.34 Proxy-Authorization
The Proxy-Authorization request-header field allows the client to
identify itself (or its user) to a proxy which requires
authentication. The Proxy-Authorization field value consists of
credentials containing the authentication information of the user
agent for the proxy and/or realm of the resource being requested.
Proxy-Authorization = "Proxy-Authorization" ":" credentials
The HTTP access authentication process is described in section 11.
Unlike Authorization, the Proxy-Authorization header field applies
only to the next outbound proxy that demanded authentication using
the Proxy-Authenticate field. When multiple proxies are used in a
chain, the Proxy-Authorization header field is consumed by the first
outbound proxy that was expecting to receive credentials. A proxy MAY
relay the credentials from the client request to the next proxy if
that is the mechanism by which the proxies cooperatively authenticate
a given request.
14.35 Public
The Public response-header field lists the set of methods supported
by the server. The purpose of this field is strictly to inform the
recipient of the capabilities of the server regarding unusual
methods. The methods listed may or may not be applicable to the
Request-URI; the Allow header field (section 14.7) MAY be used to
indicate methods allowed for a particular URI.
Public = "Public" ":" 1#method
Example of use:
Public: OPTIONS, MGET, MHEAD, GET, HEAD
This header field applies only to the server directly connected to
the client (i.e., the nearest neighbor in a chain of connections). If
the response passes through a proxy, the proxy MUST either remove the
Public header field or replace it with one applicable to its own
capabilities.
14.36 Range
14.36.1 Byte Ranges
Since all HTTP entities are represented in HTTP messages as sequences
of bytes, the concept of a byte range is meaningful for any HTTP
entity. (However, not all clients and servers need to support byte-
range operations.)
Byte range specifications in HTTP apply to the sequence of bytes in
the entity-body (not necessarily the same as the message-body).
A byte range operation may specify a single range of bytes, or a set
of ranges within a single entity.
ranges-specifier = byte-ranges-specifier
byte-ranges-specifier = bytes-unit "=" byte-range-set
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
byte-range-spec = first-byte-pos "-" [last-byte-pos]
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
The first-byte-pos value in a byte-range-spec gives the byte-offset
of the first byte in a range. The last-byte-pos value gives the
byte-offset of the last byte in the range; that is, the byte
positions specified are inclusive. Byte offsets start at zero.
If the last-byte-pos value is present, it must be greater than or
equal to the first-byte-pos in that byte-range-spec, or the byte-
range-spec is invalid. The recipient of an invalid byte-range-spec
must ignore it.
If the last-byte-pos value is absent, or if the value is greater than
or equal to the current length of the entity-body, last-byte-pos is
taken to be equal to one less than the current length of the entity-
body in bytes.
By its choice of last-byte-pos, a client can limit the number of
bytes retrieved without knowing the size of the entity.
suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT
A suffix-byte-range-spec is used to specify the suffix of the
entity-body, of a length given by the suffix-length value. (That is,
this form specifies the last N bytes of an entity-body.) If the
entity is shorter than the specified suffix-length, the entire
entity-body is used.
Examples of byte-ranges-specifier values (assuming an entity-body of
length 10000):
o The first 500 bytes (byte offsets 0-499, inclusive):
bytes=0-499
o The second 500 bytes (byte offsets 500-999, inclusive):
bytes=500-999
o The final 500 bytes (byte offsets 9500-9999, inclusive):
bytes=-500
o Or
bytes=9500-
o The first and last bytes only (bytes 0 and 9999):
bytes=0-0,-1
o Several legal but not canonical specifications of the second
500 bytes (byte offsets 500-999, inclusive):
bytes=500-600,601-999
bytes=500-700,601-999
14.36.2 Range Retrieval Requests
HTTP retrieval requests using conditional or unconditional GET
methods may request one or more sub-ranges of the entity, instead of
the entire entity, using the Range request header, which applies to
the entity returned as the result of the request:
Range = "Range" ":" ranges-specifier
A server MAY ignore the Range header. However, HTTP/1.1 origin
servers and intermediate caches SHOULD support byte ranges when
possible, since Range supports efficient recovery from partially
failed transfers, and supports efficient partial retrieval of large
entities.
If the server supports the Range header and the specified range or
ranges are appropriate for the entity:
o The presence of a Range header in an unconditional GET modifies
what is returned if the GET is otherwise successful. In other
words, the response carries a status code of 206 (Partial
Content) instead of 200 (OK).
o The presence of a Range header in a conditional GET (a request
using one or both of If-Modified-Since and If-None-Match, or
one or both of If-Unmodified-Since and If-Match) modifies what
is returned if the GET is otherwise successful and the condition
is true. It does not affect the 304 (Not Modified) response
returned if the conditional is false.
In some cases, it may be more appropriate to use the If-Range header
(see section 14.27) in addition to the Range header.
If a proxy that supports ranges receives a Range request, forwards
the request to an inbound server, and receives an entire entity in
reply, it SHOULD only return the requested range to its client. It
SHOULD store the entire received response in its cache, if that is
consistent with its cache allocation policies.
14.37 Referer
The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI) of the resource from
which the Request-URI was obtained (the "referrer", although the
header field is misspelled.) The Referer request-header allows a
server to generate lists of back-links to resources for interest,
logging, optimized caching, etc. It also allows obsolete or mistyped
links to be traced for maintenance. The Referer field MUST NOT be
sent if the Request-URI was obtained from a source that does not have
its own URI, such as input from the user keyboard.
Referer = "Referer" ":" ( absoluteURI | relativeURI )
Example:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
If the field value is a partial URI, it SHOULD be interpreted
relative to the Request-URI. The URI MUST NOT include a fragment.
Note: Because the source of a link may be private information or
may reveal an otherwise private 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.
14.38 Retry-After
The Retry-After response-header field can be used with a 503 (Service
Unavailable) response to indicate how long the service is expected to
be unavailable to the requesting client. The value of this field can
be either an HTTP-date or an integer number of seconds (in decimal)
after the time of the response.
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
In the latter example, the delay is 2 minutes.
14.39 Server
The Server response-header field contains information about the
software used by the origin server to handle the request. The field
can contain multiple product tokens (section 3.8) and comments
identifying the server and any significant subproducts. The product
tokens are listed in order of their significance for identifying the
application.
Server = "Server" ":" 1*( product | comment )
Example:
Server: CERN/3.0 libwww/2.17
If the response is being forwarded through a proxy, the proxy
application MUST NOT modify the Server response-header. Instead, it
SHOULD include a Via field (as described in section 14.44).
Note: Revealing the specific software version of the server may
allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Server
implementers are encouraged to make this field a configurable
option.
14.40 Transfer-Encoding
The Transfer-Encoding general-header field indicates what (if any)
type of transformation has been applied to the message body in order
to safely transfer it between the sender and the recipient. This
differs from the Content-Encoding in that the transfer coding is a
property of the message, not of the entity.
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-
coding
Transfer codings are defined in section 3.6. An example is:
Transfer-Encoding: chunked
Many older HTTP/1.0 applications do not understand the Transfer-
Encoding header.
14.41 Upgrade
The Upgrade general-header allows the client to specify what
additional communication protocols it supports and would like to use
if the server finds it appropriate to switch protocols. The server
MUST use the Upgrade header field within a 101 (Switching Protocols)
response to indicate which protocol(s) are being switched.
Upgrade = "Upgrade" ":" 1#product
For example,
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
The Upgrade header field is intended to provide a simple mechanism
for transition from HTTP/1.1 to some other, incompatible protocol. It
does so by allowing the client to advertise its desire to use another
protocol, such as a later version of HTTP with a higher major version
number, even though the current request has been made using HTTP/1.1.
This eases the difficult transition between incompatible protocols by
allowing the client to initiate a request in the more commonly
supported protocol while indicating to the server that it would like
to use a "better" protocol if available (where "better" is determined
by the server, possibly according to the nature of the method and/or
resource being requested).
The Upgrade header field only applies to switching application-layer
protocols upon the existing transport-layer connection. Upgrade
cannot be used to insist on a protocol change; its acceptance and use
by the server is optional. The capabilities and nature of the
application-layer communication after the protocol change is entirely
dependent upon the new protocol chosen, although the first action
after changing the protocol MUST be a response to the initial HTTP
request containing the Upgrade header field.
The Upgrade header field only applies to the immediate connection.
Therefore, the upgrade keyword MUST be supplied within a Connection
header field (section 14.10) whenever Upgrade is present in an
HTTP/1.1 message.
The Upgrade header field cannot be used to indicate a switch to a
protocol on a different connection. For that purpose, it is more
appropriate to use a 301, 302, 303, or 305 redirection response.
This specification only defines the protocol name "HTTP" for use by
the family of Hypertext Transfer Protocols, as defined by the HTTP
version rules of section 3.1 and future updates to this
specification. Any token can be used as a protocol name; however, it
will only be useful if both the client and server associate the name
with the same protocol.
14.42 User-Agent
The User-Agent request-header 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. User agents SHOULD include this field with
requests. The field can contain multiple product tokens (section 3.8)
and comments identifying the agent and any subproducts which form a
significant part of the user agent. By convention, the product tokens
are listed in order of their significance for identifying the
application.
User-Agent = "User-Agent" ":" 1*( product | comment )
Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
14.43 Vary
The Vary response-header field is used by a server to signal that the
response entity was selected from the available representations of
the response using server-driven negotiation (section 12). Field-
names listed in Vary headers are those of request-headers. The Vary
field value indicates either that the given set of header fields
encompass the dimensions over which the representation might vary, or
that the dimensions of variance are unspecified ("*") and thus may
vary over any aspect of future requests.
Vary = "Vary" ":" ( "*" | 1#field-name )
An HTTP/1.1 server MUST include an appropriate Vary header field with
any cachable response that is subject to server-driven negotiation.
Doing so allows a cache to properly interpret future requests on that
resource and informs the user agent about the presence of negotiation
on that resource. A server SHOULD include an appropriate Vary header
field with a non-cachable response that is subject to server-driven
negotiation, since this might provide the user agent with useful
information about the dimensions over which the response might vary.
The set of header fields named by the Vary field value is known as
the "selecting" request-headers.
When the cache receives a subsequent request whose Request-URI
specifies one or more cache entries including a Vary header, the
cache MUST NOT use such a cache entry to construct a response to the
new request unless all of the headers named in the cached Vary header
are present in the new request, and all of the stored selecting
request-headers from the previous request match the corresponding
headers in the new request.
The selecting request-headers from two requests are defined to match
if and only if the selecting request-headers in the first request can
be transformed to the selecting request-headers in the second request
by adding or removing linear whitespace (LWS) at places where this is
allowed by the corresponding BNF, and/or combining multiple message-
header fields with the same field name following the rules about
message headers in section 4.2.
A Vary field value of "*" signals that unspecified parameters,
possibly other than the contents of request-header fields (e.g., the
network address of the client), play a role in the selection of the
response representation. Subsequent requests on that resource can
only be properly interpreted by the origin server, and thus a cache
MUST forward a (possibly conditional) request even when it has a
fresh response cached for the resource. See section 13.6 for use of
the Vary header by caches.
A Vary field value consisting of a list of field-names signals that
the representation selected for the response is based on a selection
algorithm which considers ONLY the listed request-header field values
in selecting the most appropriate representation. A cache MAY assume
that the same selection will be made for future requests with the
same values for the listed field names, for the duration of time in
which the response is fresh.
The field-names given are not limited to the set of standard
request-header fields defined by this specification. Field names are
case-insensitive.
14.44 Via
The Via general-header field MUST be used by gateways and proxies to
indicate the intermediate protocols and recipients between the user
agent and the server on requests, and between the origin server and
the client on responses. It is analogous to the "Received" field of
RFC 822 and is intended to be used for tracking message forwards,
avoiding request loops, and identifying the protocol capabilities of
all senders along the request/response chain.
Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token
The received-protocol indicates the protocol version of the message
received by the server or client along each segment of the
request/response chain. The received-protocol version is appended to
the Via field value when the message is forwarded so that information
about the protocol capabilities of upstream applications remains
visible to all recipients.
The protocol-name is optional if and only if it would be "HTTP". The
received-by field is normally the host and optional port number of a
recipient server or client that subsequently forwarded the message.
However, if the real host is considered to be sensitive information,
it MAY be replaced by a pseudonym. If the port is not given, it MAY
be assumed to be the default port of the received-protocol.
Multiple Via field values represent each proxy or gateway that has
forwarded the message. Each recipient MUST append its information
such that the end result is ordered according to the sequence of
forwarding applications.
Comments MAY be used in the Via header field to identify the software
of the recipient proxy or gateway, analogous to the User-Agent and
Server header fields. However, all comments in the Via field are
optional and MAY be removed by any recipient prior to forwarding the
message.
For example, a request message could be sent from an HTTP/1.0 user
agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
forward the request to a public proxy at nowhere.com, which completes
the request by forwarding it to the origin server at www.ics.uci.edu.
The request received by www.ics.uci.edu would then have the following
Via header field:
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Proxies and gateways used as a portal through a network firewall
SHOULD NOT, by default, forward the names and ports of hosts within
the firewall region. This information SHOULD only be propagated if
explicitly enabled. If not enabled, the received-by host of any host
behind the firewall SHOULD be replaced by an appropriate pseudonym
for that host.
For organizations that have strong privacy requirements for hiding
internal structures, a proxy MAY combine an ordered subsequence of
Via header field entries with identical received-protocol values into
a single such entry. For example,
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
could be collapsed to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Applications SHOULD NOT combine multiple entries unless they are all
under the same organizational control and the hosts have already been
replaced by pseudonyms. Applications MUST NOT combine entries which
have different received-protocol values.
14.45 Warning
The Warning response-header field is used to carry additional
information about the status of a response which may not be reflected
by the response status code. This information is typically, though
not exclusively, used to warn about a possible lack of semantic
transparency from caching operations.
Warning headers are sent with responses using:
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 2DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
A response may carry more than one Warning header.
The warn-text should be in a natural language and character set that
is most likely to be intelligible to the human user receiving the
response. This decision may be based on any available knowledge,
such as the location of the cache or user, the Accept-Language field
in a request, the Content-Language field in a response, etc. The
default language is English and the default character set is ISO-
8859-1.
If a character set other than ISO-8859-1 is used, it MUST be encoded
in the warn-text using the method described in RFC 1522 [14].
Any server or cache may add Warning headers to a response. New
Warning headers should be added after any existing Warning headers. A
cache MUST NOT delete any Warning header that it received with a
response. However, if a cache successfully validates a cache entry,
it SHOULD remove any Warning headers previously attached to that
entry except as specified for specific Warning codes. It MUST then
add any Warning headers received in the validating response. In other
words, Warning headers are those that would be attached to the most
recent relevant response.
When multiple Warning headers are attached to a response, the user
agent SHOULD display as many of them as possible, in the order that
they appear in the response. If it is not possible to display all of
the warnings, the user agent should follow these heuristics:
o Warnings that appear early in the response take priority over those
appearing later in the response.
o Warnings in the user's preferred character set take priority over
warnings in other character sets but with identical warn-codes and
warn-agents.
Systems that generate multiple Warning headers should order them with
this user agent behavior in mind.
This is a list of the currently-defined warn-codes, each with a
recommended warn-text in English, and a description of its meaning.
10 Response is stale
MUST be included whenever the returned response is stale. A cache may
add this warning to any response, but may never remove it until the
response is known to be fresh.
11 Revalidation failed
MUST be included if a cache returns a stale response because an
attempt to revalidate the response failed, due to an inability to
reach the server. A cache may add this warning to any response, but
may never remove it until the response is successfully revalidated.
12 Disconnected operation
SHOULD be included if the cache is intentionally disconnected from
the rest of the network for a period of time.
13 Heuristic expiration
MUST be included if the cache heuristically chose a freshness
lifetime greater than 24 hours and the response's age is greater than
24 hours.
14 Transformation applied
MUST be added by an intermediate cache or proxy if it applies any
transformation changing the content-coding (as specified in the
Content-Encoding header) or media-type (as specified in the
Content-Type header) of the response, unless this Warning code
already appears in the response. MUST NOT be deleted from a response
even after revalidation.
99 Miscellaneous warning
The warning text may include arbitrary information to be presented to
a human user, or logged. A system receiving this warning MUST NOT
take any automated action.
14.46 WWW-Authenticate
The WWW-Authenticate response-header field MUST be included in 401
(Unauthorized) response messages. The field value consists of at
least one challenge that indicates the authentication scheme(s) and
parameters applicable to the Request-URI.
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
The HTTP access authentication process is described in section 11.
User agents MUST take special care in parsing the WWW-Authenticate
field value if it contains more than one challenge, or if more than
one WWW-Authenticate header field is provided, since the contents of
a challenge may itself contain a comma-separated list of
authentication parameters.
Оставить комментарий
Комментарии
1.
Аноним
27 октября 2004, 02:28:47
Если перевести по конца цены этому сайту не будет загляну сюда через пару недель.