requests.
If none of the entity tags match, then the server MAY perform the
requested method as if the If-None-Match header field did not exist,
but MUST also ignore any If-Modified-Since header field(s) in the
request. That is, if no entity tags match, then the server MUST NOT
return a 304 (Not Modified) response.
If the request would, without the If-None-Match header field, result
in anything other than a 2xx or 304 status, then the If-None-Match
header MUST be ignored. (See section 13.3.4 for a discussion of
server behavior when both If-Modified-Since and If-None-Match appear
in the same request.)
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.44)
exists, and SHOULD be performed if the representation does not exist.
This feature is intended to 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: *
The result of a request having both an If-None-Match header field and
either an If-Match or an If-Unmodified-Since header fields is
undefined by this specification.
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 an 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 or 412 status, the
If-Unmodified-Since header SHOULD be ignored.
If the specified date is invalid, the header is ignored.
The result of a request having both an If-Unmodified-Since header
field and either an If-None-Match or an If-Modified-Since header
fields is undefined by this specification.
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 URI for automatic redirection to the resource. The
field value consists of a single absolute URI.
Location = "Location" ":" absoluteURI
An example is:
Location: http://www.w3.org/pub/WWW/People.html
Note: The Content-Location header field (section 14.14) 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 provides a mechanism with the
TRACE (section 9.8) and OPTIONS (section 9.2) methods 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 or OPTIONS request
containing a Max-Forwards header field MUST check and update its
value prior to forwarding the request. If the received value is zero
(0), the recipient MUST NOT forward the request; instead, it MUST
respond as the final recipient. If the received Max-Forwards value is
greater than zero, then the forwarded message MUST contain an updated
Max-Forwards field with a value decremented by one (1).
The Max-Forwards header field MAY 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 might 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 backward 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 might 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 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.
Note: because the meaning of "Pragma: no-cache as a response
header field is not actually specified, it does not provide a
reliable replacement for "Cache-Control: no-cache" in a response
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" ":" 1#challenge
The HTTP access authentication process is described in "HTTP
Authentication: Basic and Digest Access Authentication" [43]. 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 might 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 "HTTP
Authentication: Basic and Digest Access Authentication" [43] . 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 Range
14.35.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 syntactically invalid. The recipient of a byte-range-
set that includes one or more syntactically invalid byte-range-spec
values MUST ignore the header field that includes that byte-range-
set.
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.
If a syntactically valid byte-range-set includes at least one byte-
range-spec whose first-byte-pos is less than the current length of
the entity-body, or at least one suffix-byte-range-spec with a non-
zero suffix-length, then the byte-range-set is satisfiable.
Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
is unsatisfiable, the server SHOULD return a response with a status
of 416 (Requested range not satisfiable). Otherwise, the server
SHOULD return a response with a status of 206 (Partial Content)
containing the satisfiable ranges of the entity-body.
Examples of byte-ranges-specifier values (assuming an entity-body of
length 10000):
- The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-
499
- The second 500 bytes (byte offsets 500-999, inclusive):
bytes=500-999
- The final 500 bytes (byte offsets 9500-9999, inclusive):
bytes=-500
- Or bytes=9500-
- The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1
- 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.35.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 ought to 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:
- 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).
- 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 might 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.36 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 relative URI, it SHOULD be interpreted
relative to the Request-URI. The URI MUST NOT include a fragment. See
section 15.1.3 for security considerations.
14.37 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. This field MAY also be used
with any 3xx (Redirection) response to indicate the minimum time the
user-agent is asked wait before issuing the redirected request. 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.38 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.45).
Note: Revealing the specific software version of the server might
allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Server
implementors are encouraged to make this field a configurable
option.
14.39 TE
The TE request-header field indicates what extension transfer-codings
it is willing to accept in the response and whether or not it is
willing to accept trailer fields in a chunked transfer-coding. Its
value may consist of the keyword "trailers" and/or a comma-separated
list of extension transfer-coding names with optional accept
parameters (as described in section 3.6).
TE = "TE" ":" #( t-codings )
t-codings = "trailers" | ( transfer-extension [ accept-params ] )
The presence of the keyword "trailers" indicates that the client is
willing to accept trailer fields in a chunked transfer-coding, as
defined in section 3.6.1. This keyword is reserved for use with
transfer-coding values even though it does not itself represent a
transfer-coding.
Examples of its use are:
TE: deflate
TE:
TE: trailers, deflate;q=0.5
The TE header field only applies to the immediate connection.
Therefore, the keyword MUST be supplied within a Connection header
field (section 14.10) whenever TE is present in an HTTP/1.1 message.
A server tests whether a transfer-coding is acceptable, according to
a TE field, using these rules:
1. The "chunked" transfer-coding is always acceptable. If the
keyword "trailers" is listed, the client indicates that it is
willing to accept trailer fields in the chunked response on
behalf of itself and any downstream clients. The implication is
that, if given, the client is stating that either all
downstream clients are willing to accept trailer fields in the
forwarded response, or that it will attempt to buffer the
response on behalf of downstream recipients.
Note: HTTP/1.1 does not define any means to limit the size of a
chunked response such that a client can be assured of buffering
the entire response.
2. If the transfer-coding being tested is one of the transfer-
codings listed in the TE field, then it is acceptable unless it
is accompanied by a qvalue of 0. (As defined in section 3.9, a
qvalue of 0 means "not acceptable.")
3. If multiple transfer-codings are acceptable, then the
acceptable transfer-coding with the highest non-zero qvalue is
preferred. The "chunked" transfer-coding always has a qvalue
of 1.
If the TE field-value is empty or if no TE field is present, the only
transfer-coding is "chunked". A message with no transfer-coding is
always acceptable.
14.40 Trailer
The Trailer general field value indicates that the given set of
header fields is present in the trailer of a message encoded with
chunked transfer-coding.
Trailer = "Trailer" ":" 1#field-name
An HTTP/1.1 message SHOULD include a Trailer header field in a
message using chunked transfer-coding with a non-empty trailer. Doing
so allows the recipient to know which header fields to expect in the
trailer.
If no Trailer header field is present, the trailer SHOULD NOT include
any header fields. See section 3.6.1 for restrictions on the use of
trailer fields in a "chunked" transfer-coding.
Message header fields listed in the Trailer header field MUST NOT
include the following header fields:
. Transfer-Encoding
. Content-Length
. Trailer
14.41 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-coding 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
If multiple encodings have been applied to an entity, the transfer-
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.
Many older HTTP/1.0 applications do not understand the Transfer-
Encoding header.
14.42 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.43 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.44 Vary
The Vary field value indicates the set of request-header fields that
fully determines, while the response is fresh, whether a cache is
permitted to use the response to reply to a subsequent request
without revalidation. For uncacheable or stale responses, the Vary
field value advises the user agent about the criteria that were used
to select the representation. A Vary field value of "*" implies that
a cache cannot determine from the request headers of a subsequent
request whether this response is the appropriate representation. See
section 13.6 for use of the Vary header field by caches.
Vary = "Vary" ":" ( "*" | 1#field-name )
An HTTP/1.1 server SHOULD include a Vary header field with any
cacheable 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 MAY include a Vary header field with a
non-cacheable 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 varies at the time of the
response.
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 for
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.
A Vary field value of "*" signals that unspecified parameters not
limited to the request-headers (e.g., the network address of the
client), play a role in the selection of the response representation.
The "*" value MUST NOT be generated by a proxy server; it may only be
generated by an origin server.
14.45 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
RFC822 [9] 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 represents 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.46 Warning
The Warning general-header field is used to carry additional
information about the status or transformation of a message which
might not be reflected in the message. This information is typically
used to warn about a possible lack of semantic transparency from
caching operations or transformations applied to the entity body of
the message.
Warning headers are sent with responses using:
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
[SP warn-date]
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
warn-date = <"> HTTP-date <">
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 RFC2047 [14].
Warning headers can in general be applied to any message, however
some specific warn-codes are specific to caches and can only be
applied to response messages. New Warning headers SHOULD be added
after any existing Warning headers. A cache MUST NOT delete any
Warning header that it received with a message. 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 ought to inform the user of as many of them as possible, in the
order that they appear in the response. If it is not possible to
inform the user of all of the warnings, the user agent SHOULD follow
these heuristics:
- Warnings that appear early in the response take priority over
those appearing later in the response.
- 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.
Requirements for the behavior of caches with respect to Warnings are
stated in section 13.1.2.
This is a list of the currently-defined warn-codes, each with a
recommended warn-text in English, and a description of its meaning.
110 Response is stale
MUST be included whenever the returned response is stale.
111 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.
112 Disconnected operation
SHOULD be included if the cache is intentionally disconnected from
the rest of the network for a period of time.
113 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.
199 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, besides presenting the warning to
the user.
214 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, or the entity-body of the
response, unless this Warning code already appears in the response.
299 Miscellaneous persistent 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.
If an implementation sends a message with one or more Warning headers
whose version is HTTP/1.0 or lower, then the sender MUST include in
each warning-value a warn-date that matches the date in the response.
If an implementation receives a message with a warning-value that
includes a warn-date, and that warn-date is different from the Date
value in the response, then that warning-value MUST be deleted from
the message before storing, forwarding, or using it. (This prevents
bad consequences of naive caching of Warning header fields.) If all
of the warning-values are deleted for this reason, the Warning header
MUST be deleted as well.
14.47 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 "HTTP
Authentication: Basic and Digest Access Authentication" [43]. User
agents are advised to take special care in parsing the WWW-
Authenticate field value as it might contain more than one challenge,
or if more than one WWW-Authenticate header field is provided, the
contents of a challenge itself can contain a comma-separated list of
authentication parameters.
15 Security Considerations
This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as
described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks.
15.1 Personal Information
HTTP clients are often privy to large amounts of personal information
(e.g. the user's name, location, mail address, passwords, encryption
keys, etc.), and SHOULD be very careful to prevent unintentional
leakage of this information via the HTTP protocol to other sources.
We very strongly recommend that a convenient interface be provided
for the user to control dissemination of such information, and that
designers and implementors be particularly careful in this area.
History shows that errors in this area often create serious security
and/or privacy problems and generate highly adverse publicity for the
implementor's company.
15.1.1 Abuse of Server Log Information
A server is in the position to save personal data about a user's
requests which might identify their reading patterns or subjects of
interest. This information is clearly confidential in nature and its
handling can be constrained by law in certain countries. People using
the HTTP protocol to provide data are responsible for ensuring that
such material is not distributed without the permission of any
individuals that are identifiable by the published results.
15.1.2 Transfer of Sensitive Information
Like any generic data transfer protocol, HTTP cannot regulate the
content of the data that is transferred, nor is there any a priori
method of determining the sensitivity of any particular piece of
information within the context of any given request. Therefore,
applications SHOULD supply as much control over this information as
possible to the provider of that information. Four header fields are
worth special mention in this context: Server, Via, Referer and From.
Revealing the specific software version of the server might allow the
server machine to become more vulnerable to attacks against software
that is known to contain security holes. Implementors SHOULD make the
Server header field a configurable option.
Proxies which serve as a portal through a network firewall SHOULD
take special precautions regarding the transfer of header information
that identifies the hosts behind the firewall. In particular, they
SHOULD remove, or replace with sanitized versions, any Via fields
generated behind the firewall.
The Referer header allows reading patterns to be studied and reverse
links drawn. Although it can be very useful, its power can be abused
if user details are not separated from the information contained in
the Referer. Even when the personal information has been removed, the
Referer header might indicate a private document's URI whose
publication would be inappropriate.
The information sent in the From field might conflict with the user's
privacy interests or their site's security policy, and hence it
SHOULD NOT be transmitted without the user being able to disable,
enable, and modify the contents of the field. The user MUST be able
to set the contents of this field within a user preference or
application defaults configuration.
We suggest, though do not require, that a convenient toggle interface
be provided for the user to enable or disable the sending of From and
Referer information.
The User-Agent (section 14.43) or Server (section 14.38) header
fields can sometimes be used to determine that a specific client or
server have a particular security hole which might be exploited.
Unfortunately, this same information is often used for other valuable
purposes for which HTTP currently has no better mechanism.
15.1.3 Encoding Sensitive Information in URI's
Because the source of a link might be private information or might
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.
Clients SHOULD NOT include a Referer header field in a (non-secure)
HTTP request if the referring page was transferred with a secure
protocol.
Authors of services which use the HTTP protocol SHOULD NOT use GET
based forms for the submission of sensitive data, because this will
cause this data to be encoded in the Request-URI. Many existing
servers, proxies, and user agents will log the request URI in some
place where it might be visible to third parties. Servers can use
POST-based form submission instead
15.1.4 Privacy Issues Connected to Accept Headers
Accept request-headers can reveal information about the user to all
servers which are accessed. The Accept-Language header in particular
can reveal information the user would consider to be of a private
nature, because the understanding of particular languages is often
strongly correlated to the membership of a particular ethnic group.
User agents which offer the option to configure the contents of an
Accept-Language header to be sent in every request are strongly
encouraged to let the configuration process include a message which
makes the user aware of the loss of privacy involved.
An approach that limits the loss of privacy would be for a user agent
to omit the sending of Accept-Language headers by default, and to ask
the user whether or not to start sending Accept-Language headers to a
server if it detects, by looking for any Vary response-header fields
generated by the server, that such sending could improve the quality
of service.
Elaborate user-customized accept header fields sent in every request,
in particular if these include quality values, can be used by servers
as relatively reliable and long-lived user identifiers. Such user
identifiers would allow content providers to do click-trail tracking,
and would allow collaborating content providers to match cross-server
click-trails or form submissions of individual users. Note that for
many users not behind a proxy, the network address of the host
running the user agent will also serve as a long-lived user
identifier. In environments where proxies are used to enhance
privacy, user agents ought to be conservative in offering accept
header configuration options to end users. As an extreme privacy
measure, proxies could filter the accept headers in relayed requests.
General purpose user agents which provide a high degree of header
configurability SHOULD warn users about the loss of privacy which can
be involved.
15.2 Attacks Based On File and Path Names
Implementations of HTTP origin servers SHOULD be careful to restrict
the documents returned by HTTP requests to be only those that were
intended by the server administrators. If an HTTP server translates
HTTP URIs directly into file system calls, the server MUST take
special care not to serve files that were not intended to be
delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
other operating systems use ".." as a path component to indicate a
directory level above the current one. On such a system, an HTTP
server MUST disallow any such construct in the Request-URI if it
would otherwise allow access to a resource outside those intended to
be accessible via the HTTP server. Similarly, files intended for
reference only internally to the server (such as access control
files, configuration files, and script code) MUST be protected from
inappropriate retrieval, since they might contain sensitive
information. Experience has shown that minor bugs in such HTTP server
implementations have turned into security risks.
15.3 DNS Spoofing
Clients using HTTP rely heavily on the Domain Name Service, and are
thus generally prone to security attacks based on the deliberate
mis-association of IP addresses and DNS names. Clients need to be
cautious in assuming the continuing validity of an IP number/DNS name
association.
In particular, HTTP clients SHOULD rely on their name resolver for
confirmation of an IP number/DNS name association, rather than
caching the result of previous host name lookups. Many platforms
already can cache host name lookups locally when appropriate, and
they SHOULD be configured to do so. It is proper for these lookups to
be cached, however, only when the TTL (Time To Live) information
reported by the name server makes it likely that the cached
information will remain useful.
If HTTP clients cache the results of host name lookups in order to
achieve a performance improvement, they MUST observe the TTL
information reported by DNS.
If HTTP clients do not observe this rule, they could be spoofed when
a previously-accessed server's IP address changes. As network
renumbering is expected to become increasingly common [24], the
possibility of this form of attack will grow. Observing this
requirement thus reduces this potential security vulnerability.
This requirement also improves the load-balancing behavior of clients
for replicated servers using the same DNS name and reduces the
likelihood of a user's experiencing failure in accessing sites which
use that strategy.
15.4 Location Headers and Spoofing
If a single server supports multiple organizations that do not trust
one another, then it MUST check the values of Location and Content-
Location headers in responses that are generated under control of
said organizations to make sure that they do not attempt to
invalidate resources over which they have no authority.
15.5 Content-Disposition Issues
RFC1806 [35], from which the often implemented Content-Disposition
(see section 19.5.1) header in HTTP is derived, has a number of very
serious security considerations. Content-Disposition is not part of
the HTTP standard, but since it is widely implemented, we are
documenting its use and risks for implementors. See RFC2183 [49]
(which updates RFC1806) for details.
15.6 Authentication Credentials and Idle Clients
Existing HTTP clients and user agents typically retain authentication
information indefinitely. HTTP/1.1. does not provide a method for a