1 - 2 - 7 - 8 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - X
header field
Click on the red underlined text to get to the source
... entity consists of metainformation in the form of
entity-header fields and content in the form of an entity-body, as
described in section 7.
...
...
Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted
string to be used within a parameter value ...
... versions of HTTP may involve modification
of header fields required or forbidden by the versions involved.
...
... 1123std3 format for representing HTTP-date values
in header fields.
Note: Recipients of date values are encouraged to be robust in
...
... Encoding (section 14.3) and
Content-Encoding (section 14.12) header fields. Although the value
describes the content-coding, what is more important is that it
indicates what decoding mechanism will be required to remove ...
... transfer it as a series of chunks, each with its own size indicator,
followed by an optional footer containing entity-header fields. This
allows dynamically-produced content to be transferred along with the
information necessary for the recipient to verify that it has
...
... entity that is generated dynamically; applications MUST NOT send
header fields in the footer which are not explicitly defined as being
appropriate for the footer, such as Content-MD5 or future extensions
...
... Media Types in the Content-Type (section 14.18)
and Accept (section 14.1) header fields in order to provide open and
extensible data typing and type negotiation.
...
... CRLF within any of the HTTP control
structures (such as header fields and multipart boundaries).
If an entity ...
...
In HTTP, multipart body-parts MAY contain header fields which are
significant to the meaning of that part. A Content-Location header
field ...
... header fields which are
significant to the meaning of that part. A Content-Location header
field (section 14.15) SHOULD be included in the body-part of each
enclosed entity that can be identified by a URL ...
... 14.20), If-Match (section 14.25), If-None-Match (section 14.26), and
If-Range (section 14.27) header fields. The definition of how they
are used and compared as cache validators is in section 13.3.3. An
...
... Range (section 14.36) and Content-Range (section 14.17)
header fields. An entity may be broken down into subranges according
to various structural units.
...
... of the message). Both types of message consist of a start-line, one
or more header fields (also known as "headers"), an empty line (i.e.,
a line with nothing preceding the CRLF ...
... a line with nothing preceding the CRLF) indicating the end of the
header fields, and an optional message-body.
...
... that given in Section 3.1 of RFC 822std11(-> 2822prop) [9]. Each header field consists
of a name followed by a colon (":") and the field value. Field names
are case-insensitive ...
... case-insensitive. The field value may be preceded by any amount
of LWS, though a single SP is preferred. Header fields can be
extended over multiple lines by preceding each extra line with at
least one SP ...
... token, tspecials, and quoted-string>
The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send
general-header fields ...
... header fields with differing field names are
received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response-
header fields ...
... header fields first, followed by request-header or response-
header fields, and ending with the entity-header fields.
...
... field-name may be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
...
... header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics ...
... semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
...
... entity-body only when a transfer coding has been
applied, as indicated by the Transfer-Encoding header field (section
14.40).
...
... inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body ...
... message-body, even though the presence of entity-
header fields might lead one to believe they do. All 1xx
(informational), 204 (no content), and 304 (not modified) responses
MUST NOT include a message-body ...
... (such as the 1xx, 204, and 304 responses and any response to a HEAD
request) is always terminated by the first empty line after the
header fields, regardless of the entity-header fields present in the
...
...
2. If a Transfer-Encoding header field (section 14.40) is present and
indicates that the "chunked" transfer coding has been applied, then
...
...
3. If a Content-Length header field (section 14.14) is present, its
value in bytes represents the length of the message-body.
...
... message-body MUST include a valid Content-Length header
field unless the server is known to be HTTP/1.1 compliant. If a
request contains a message-body ...
...
Messages MUST NOT include both a Content-Length header field and the
"chunked" transfer coding. If both are received, the Content-Length
...
... General Header Fields ...
...
There are a few header fields which have general applicability for
both request and response messages, but which do not apply to the
...
... request and response messages, but which do not apply to the
entity being transferred. These header fields apply only to the
message being transmitted.
...
... | Via ; Section 14.44
General-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
...
... version. However, new or
experimental header fields may be given the semantics of general
header fields ...
... header fields may be given the semantics of general
header fields if all parties in the communication recognize them to
be general-header fields. Unrecognized header fields ...
... header fields if all parties in the communication recognize them to
be general-header fields. Unrecognized header fields are treated as
entity ...
... header fields if all parties in the communication recognize them to
be general-header fields. Unrecognized header fields are treated as
entity-header fields ...
... The list of methods allowed by a resource can be specified in an
Allow header field (section 14.7). The return code of the response
always notifies the client ...
... by the server. The list of methods known by a server
can be listed in a Public response-header field (section 14.35).
The methods ...
... URI (net_loc) MUST
be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would
...
... Request-URI and the Host header field.
An origin server that does not allow resources to differ by the
...
... requested host MAY ignore the Host header field value. (But see
section 19.5.1 for other requirements on Host ...
... Request-URI is not an absoluteURI, and the request
includes a Host header field, the host is determined by the Host
...
... Recipients of an HTTP/1.0 request that lacks a Host header field MAY
attempt to use heuristics (e.g., examination of the URI ...
... Request Header Fields ...
... version. However, new or
experimental header fields MAY be given the semantics of request-
header fields ...
... header fields MAY be given the semantics of request-
header fields if all parties in the communication recognize them to
be request-header fields. Unrecognized header fields ...
... header fields if all parties in the communication recognize them to
be request-header fields. Unrecognized header fields are treated as
entity-header fields ...
... Response Header Fields ...
...
The response-header fields allow the server to pass additional
information about the response which cannot be placed in the Status-
Line. These header fields ...
... header fields allow the server to pass additional
information about the response which cannot be placed in the Status-
Line. These header fields give information about the server and about
further access to the resource identified by the Request-URI.
...
... WWW-Authenticate ; Section 14.46
Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
...
... version. However, new or
experimental header fields MAY be given the semantics of response-
header fields ...
... header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields ...
... header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as
entity ...
... header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as
entity-header fields ...
... entity
consists of entity-header fields and an entity-body, although some
responses will only include the entity ...
... Entity Header Fields ...
...
Entity-header fields define optional metainformation about the
entity-body or, if no body is present, about the resource identified
...
... The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields ...
... header fields
to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and forwarded by proxies.
...
... entity-body is included with a message, the data type of that
body is determined via the header fields Content-Type and Content-
Encoding ...
... entity-body SHOULD include a
Content-Type header field defining the media type of that body. If
and only if the media type ...
... signaling takes
place using the Connection header field. Once a close has been
signaled, the client MUST not send any more requests on that
...
... proxies correctly implement the
properties of the Connection header field as specified in 14.2.1.
The proxy server ...
... client
o MUST first send the request header fields, and then
o MUST wait for the server to respond with either a 100 (Continue)
...
... Request-URI is an asterisk ("*"), the OPTIONS request is
intended to apply to the server as a whole. A 200 response SHOULD
include any header fields which indicate optional features
implemented by the server (e.g., Public), including any extensions
...
... by the server (e.g., Public), including any extensions
not defined by this specification, in addition to any applicable
general or response-header fields. As described in section 5.1.2, an
"OPTIONS *" request can be applied through a proxy by specifying the
...
... Request-URI is not an asterisk, the OPTIONS request applies
only to the options that are available when communicating with that
resource. A 200 response SHOULD include any header fields which
indicate optional features implemented by the server and applicable
...
... to that resource (e.g., Allow), including any extensions not defined
by this specification, in addition to any applicable general or
response-header fields. If the OPTIONS request passes through a
proxy, the proxy ...
... request message includes an If-Modified-Since, If-Unmodified-Since,
If-Match, If-None-Match, or If-Range header field. A conditional GET
method requests that the entity be transferred only under the
...
... GET
method requests that the entity be transferred only under the
circumstances described by the conditional header field(s). The
conditional GET method is intended to reduce unnecessary network ...
... request message includes a Range header field. A partial GET requests
that only part of the entity be transferred, as described in section
...
... method are not cachable, unless the response
includes appropriate Cache-Control or Expires header fields. However,
the 303 (See Other) response can be used to direct the user agent to
...
... client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic
information. The value of the Via header field (section 14.44) is of
particular interest, since it acts as a trace of the request chain.
...
... particular interest, since it acts as a trace of the request chain.
Use of the Max-Forwards header field allows the client to limit the
length of the request chain, which is useful for testing a chain of
...
... server will switch protocols to those defined by the response's
Upgrade header field immediately after the empty line which
terminates the 101 response.
...
...
HEAD the entity-header fields corresponding to the requested resource
are sent in the response without any message-body;
...
... entity of the response, with the most specific URL
for the resource given by a Location header field. The origin server
MUST create the resource before returning the 201 status code ...
... The 204 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.
...
... The server has fulfilled the partial GET request for the resource.
The request must have included a Range header field (section 14.36)
indicating the desired range. The response MUST include either a
...
... range. The response MUST include either a
Content-Range header field (section 14.17) indicating the range
included with this response, or a multipart/byteranges Content-Type ...
... Range fields for each part. If multipart/byteranges
is not used, the Content-Length header field in the response MUST
match the actual number of OCTETs transmitted in the message-body.
...
... entity format is specified by the media type given in the Content-
Type header field. Depending upon the format and the capabilities of
the user agent, selection of the most appropriate choice may be
...
... Request-URI for future requests. This response is
only cachable if indicated by a Cache-Control or Expires header
field.
If the new URI ...
... message-body.
The response MUST include the following header fields:
o Date
...
... The 304 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.
...
... user authentication. The response MUST include a
WWW-Authenticate header field (section 14.46) containing a challenge
applicable to the requested resource. The client MAY repeat the
...
... client MAY repeat the
request with a suitable Authorization header field (section 14.8). If
the request already included Authorization credentials ...
... media type given
in the Content-Type header field. Depending upon the format and the
capabilities of the user agent, selection of the most appropriate
...
... return a Proxy-Authenticate header field (section 14.33) containing a
challenge applicable to the proxy for the requested resource. The
...
... Proxy-Authorization
header field (section 14.34). HTTP access authentication is explained
in section 11.
...
... valid
Content-Length header field containing the length of the message-body
in the request message ...
... response
code allows the client to place preconditions on the current resource
metainformation (header field data) and thus prevent the requested
method from being applied to a resource other than the one intended.
...
...
If the condition is temporary, the server SHOULD include a Retry-
After header field to indicate that it is temporary and after what
time the client may try again.
...
... user agent. This response MUST
include a WWW-Authenticate header field containing at least one
challenge applicable to the requested resource.
...
... receiving a 401 or 411 response-
-MAY do so by including an Authorization header field with the
request. The Authorization field value consists of credentials ...
... request, it SHOULD return a 401 (Unauthorized) response. The response
MUST include a WWW-Authenticate header field containing the (possibly
new) challenge applicable to the requested resource and an entity
...
... user agent wishes to send the userid "Aladdin" and password
"open sesame", it would use the following header field:
Authorization ...
... the response (the dimensions over which it can vary; e.g. language,
content-coding, etc.) and the contents of particular header fields in
the request message or on other information pertaining to the request
...
... guess" is good enough for the user). In order to improve the server's
guess, the user agent MAY include request header fields (Accept,
Accept-Language, Accept-Encoding ...
...
HTTP/1.1 origin servers MUST include an appropriate Vary header field
(section 14.43) in any cachable response based on server-driven
negotiation ...
... (section 14.43) in any cachable response based on server-driven
negotiation. The Vary header field describes the dimensions over
which the response might vary (i.e. the dimensions over which the
origin server picks its "best guess" response from multiple
...
... HTTP/1.1 public caches MUST recognize the Vary header field when it
is included in a response and obey the requirements described in
...
... initial response from the origin server. Selection is based on a list
of the available representations of the response included within the
header fields (this specification reserves the field-name Alternates,
as described in appendix 19.6.2.1) or entity ...
... cache performing transparent negotiation MUST include a Vary header
field in the response (defining the dimensions of its variance) if it
is cachable to ensure correct interoperation with all HTTP/1.1
...
...
The Last-Modified entity-header field value is often used as a cache
validator. In simple terms, a cache ...
... A "use" of a validator is either when a client generates a request
and includes the validator in a validating header field, or when a
server compares two validators.
...
... later versions of HTTP. Such authentication
mechanisms may rely on the values of header fields not listed here.
...
... section 14.45) to this set.
If a header field-name in the incoming response matches more than one
header in the cache ...
... Use of server-driven content negotiation (section 12), as indicated
by the presence of a Vary header field in a response, alters the
conditions and procedure by which a cache can use the response for
...
... subsequent requests.
A server MUST use the Vary header field (section 14.43) to inform a
cache of what header field ...
... header field (section 14.43) to inform a
cache of what header field dimensions are used to select among
multiple representations of a cachable response. A cache may use the
...
... response) for replying to subsequent requests on that resource only
when the subsequent requests have the same or equivalent values for
all header fields specified in the Vary response-header. Requests
with a different value for one or more of those header fields ...
... header fields specified in the Vary response-header. Requests
with a different value for one or more of those header fields would
be forwarded toward the origin server.
...
... entity tags in an If-
None-Match header field from all its cache entries for the Request-
URI ...
...
new response SHOULD be used to update the header fields of the
existing entry, and the result MUST be returned to the client.
...
... client.
The Vary header field may also inform the cache that the
representation was selected using criteria not limited to the
...
... Header Field Definitions ...
... syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields, both sender ...
... HTTP/1.1 header fields. For entity-header fields, both sender and
recipient refer to either the client ...
... 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 ...
... 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
...
... 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.
...
...
The Accept-Ranges response-header field allows the server to indicate
its acceptance of range requests for a resource:
...
...
The Age response-header field conveys the sender's estimate of the
amount of time since the response (or its revalidation) was generated
...
...
The Allow entity-header field lists the set of methods supported by
the resource identified by the Request-URI ...
... valid methods associated with
the resource. An Allow header field MUST be present in a 405 (Method
Not Allowed) response.
...
... 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
...
...
A proxy MUST NOT modify the Allow header field even if it does not
understand all the methods specified, since the user agent ...
... 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 ...
... 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
...
...
The Cache-Control general-header field is used to specify directives
that MUST be obeyed by all caching mechanisms along the
request/response ...
... versions of the HTTP protocol may apply these directives to
header fields not defined in HTTP/1.1.
...
... 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 ...
...
The Cache-Control header field can be extended through the use of one
or more cache-extension tokens ...
...
A cache seeing this header field will act correctly even if the cache
does not understand the "community" cache ...
...
The Connection general-header field allows the sender to specify
options that are desired for that particular connection ...
... HTTP/1.1 proxies MUST parse the Connection header field before a
message is forwarded and, for each connection-token ...
... token in this field,
remove any header field(s) from the message with the same name as the
connection-token ...
... connection-token in the Connection header field, not by any
corresponding additional header field(s), since the additional header ...
... Connection: close
in either the request or the response header fields indicates that
the connection should not be considered `persistent' (section 8.1)
...
... The Content-Base entity-header field may be used to specify the base
URI for resolving relative URLs within the entity ...
... base
URI for resolving relative URLs within the entity. This header field
is described as Base in RFC 1808(-> 3986std66), which is expected to be revised.
...
... The Content-Encoding entity-header field is used as a modifier to the
media-type. When present, its value indicates what additional content
...
... media-type
referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing
...
... encoding parameters MAY be provided
by other entity-header fields not defined by this specification.
...
... The Content-Language entity-header field describes the natural
language(s) of the intended audience for the enclosed entity ...
... The Content-Length entity-header field indicates the size of the
message-body, in decimal number of octets, sent to the recipient or,
...
... The Content-Location entity-header field may be used to supply the
resource location for the entity enclosed in the message. In the case
...
...
If no Content-Base header field is present, the value of Content-
Location also defines the base URL for the entity ...
...
The Content-MD5 header field may be generated by an origin server to
function as an integrity check of the entity ...
... entity-body. Only origin
servers may generate the Content-MD5 header field; proxies and
gateways ...
... gateways and proxies, MAY check that the digest value in
this header field matches that of the entity-body as received.
...
... Content-MD5 digest as is -- i.e.,
after the application. The Transfer-Encoding header field is not
allowed within body-parts.
...
... 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 Date general-header field represents the date and time at which
the message was originated, having the same semantics as orig-date in
...
... 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 ...
... 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
...
... 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.
...
...
The Expires entity-header field gives the date/time after which the
response should be considered stale. A stale cache ...
... 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
...
... non-cacheable indicates that the response is cachable, unless
indicated otherwise by a Cache-Control header field (section 14.9).
...
... 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
...
...
Note: The client SHOULD not send the From header field without the
user's approval, as it may conflict with the user's privacy
...
... request message
which lacks a Host header field.
See sections 5.2 and 19.5.1 for other requirements ...
... 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 ...
... entity exists for that resource, then the server MAY
perform the requested method as if the If-Match header field did not
exist.
...
... 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
...
... 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 ...
... 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 ...
... Modified) response, including the cache-related entity-header fields
(particularly ETag) of one of the entities that matched. For all
other request methods ...
... 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 ...
... 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
...
...
The Last-Modified entity-header field indicates the date and time at
which the origin server believes the variant was last modified.
...
... 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 ...
...
The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the
...
...
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 ...
... 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
...
... 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 ...
...
The Pragma general-header field is used to include implementation-
specific directives that may apply to any recipient along the
request/response ...
... 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 ...
... The Proxy-Authenticate response-header field MUST be included as part
of a 407 (Proxy Authentication Required ...
... WWW-Authenticate, the Proxy-Authenticate header field applies
only to the current connection and SHOULD NOT be passed on to
...
... Authorization, the Proxy-Authorization header field applies
only to the next outbound proxy that demanded authentication ...
... chain, the Proxy-Authorization header field is consumed by the first
outbound proxy that was expecting to receive credentials ...
...
Request-URI; the Allow header field (section 14.7) MAY be used to
indicate methods allowed for a particular URI ...
... Public: OPTIONS, MGET, MHEAD, GET, HEAD
This header field applies only to the server directly connected to
the client (i.e., the nearest neighbor ...
... proxy MUST either remove the
Public header field or replace it with one applicable to its own
capabilities.
...
... 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 ...
...
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 ...
...
The Transfer-Encoding general-header field indicates what (if any)
type of transformation has been applied to the message body in order
...
... switch protocols. The server
MUST use the Upgrade header field within a 101 (Switching Protocols)
response to indicate which protocol(s) are being switched.
...
... x11
The Upgrade header field is intended to provide a simple mechanism
for transition from HTTP/1.1 to some other, incompatible protocol. It
...
... resource being requested).
The Upgrade header field only applies to switching application-layer
protocols upon the existing transport-layer ...
... 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 ...
... header field.
The Upgrade header field only applies to the immediate connection.
Therefore, the upgrade keyword MUST be supplied within a 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.
...
... HTTP/1.1 message.
The Upgrade header field cannot be used to indicate a switch to a
protocol on a different connection ...
...
The Vary response-header field is used by a server to signal that the
response entity was selected from the available representations of
...
... 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
...
...
An HTTP/1.1 server MUST include an appropriate Vary header field with
any cachable response that is subject to server-driven negotiation ...
... 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 ...
... 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.
...
... 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.
...
... forwarding applications.
Comments MAY be used in the Via header field to identify the software
of the recipient proxy or gateway ...
... 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
...
... 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)
...
... 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,
...
...
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 ...
...
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 ...
... 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 ...
... 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.
...
... security holes. Implementers SHOULD make the
Server header field a configurable option.
Proxies ...
... 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 ...
... 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 ...
... Meyers, J., and M. Rose "The Content-MD5 Header Field", RFC 1864draft, Carnegie Mellon, Dover Beach Consulting, October, 1995. ...
... Proxies and gateways from
other protocols SHOULD ensure that any Date header field present in a
message conforms to one of the HTTP/1.1 formats and rewrite the date
...
... either change the value of the Content-Type header field or decode
the entity-body before forwarding the message. (Some experimental ...
...
In MIME, most header fields in multipart body-parts are generally
ignored unless the field name begins with "Content-". In HTTP/1.1,
...
... HTTP/1.1 messages may include a single MIME-Version general-header
field to indicate what version of the MIME protocol was used to
...
... MIME protocol was used to
construct the message. Use of the MIME-Version header field indicates
that the message is in full compliance with the MIME protocol.
...
... version of the resource being patched
included a Content-Version header field, the request entity MUST
include a Derived-From header field ...
... header field, the request entity MUST
include a Derived-From header field corresponding to the value of the
original Content-Version header field ...
... header field corresponding to the value of the
original Content-Version header field. Applications are encouraged to
use these fields for constructing versioning relationships and
resolving version ...
...
The Alternates response-header field has been proposed as a means for
the origin server to inform the client about other available
...
... negotiation in section 12).
The Alternates header field is orthogonal to the Vary header field in
that both may coexist in a message without affecting the
...
...
The Alternates header field is orthogonal to the Vary header field in
that both may coexist in a message without affecting the
interpretation of the response or the available representations. It
...
... language.
The Alternates header field will be defined in a future
specification.
...
... The Link entity-header field provides a means for describing a
relationship between two resources, generally between the requested
resource and some other resource. An entity ...
...
The URI header field has, in past versions of this specification,
been used as a combination of the existing Location, Content-
...
... versions of this specification,
been used as a combination of the existing Location, Content-
Location, and Vary header fields as well as the future Alternates
field (above). Its primary purpose has been to include a list of
...
... Furthermore, we believe that the identification of names and mirror
locations would be better performed via the Link header field. The
URI header field ...
... token has been transmitted with a
request or a response, a Keep-Alive header field MAY also be
included. The Keep-Alive header field ...
... header field MAY also be
included. The Keep-Alive header field takes the following form:
Keep-Alive ...