RFC 2068 HTTP/1.1 January 1997
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
Fielding, et. al. Standards Track [Page 134]
RFC 2068 HTTP/1.1 January 1997
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.