Fielding, et. al. Standards Track [Page 55]
RFC 2068 HTTP/1.1 January 1997
response is primarily intended to allow input for actions to take
place without causing a change to the user agent's active document
view. The response MAY include new metainformation in the form of
entity-headers, which SHOULD apply to the document currently in the
user agent's active view.
The 204 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.
10.2.6 205 Reset Content
The server has fulfilled the request and the user agent SHOULD reset
the document view which caused the request to be sent. This response
is primarily intended to allow input for actions to take place via
user input, followed by a clearing of the form in which the input is
given so that the user can easily initiate another input action. The
response MUST NOT include an entity.
10.2.7 206 Partial Content
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
Content-Range header field (section 14.17) indicating the range
included with this response, or a multipart/byteranges Content-Type
including Content-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.
A cache that does not support the Range and Content-Range headers
MUST NOT cache 206 (Partial) responses.
10.3 Redirection 3xx
This class of status code indicates that further action needs to be
taken by the user agent in order to fulfill the request. The action
required MAY be carried out by the user agent without interaction
with the user if and only if the method used in the second request is
GET or HEAD. A user agent SHOULD NOT automatically redirect a request
more than 5 times, since such redirections usually indicate an
infinite loop.
Fielding, et. al. Standards Track [Page 56]
RFC 2068 HTTP/1.1 January 1997
10.3.1 300 Multiple Choices
The requested resource corresponds to any one of a set of
representations, each with its own specific location, and agent-
driven negotiation information (section 12) is being provided so that
the user (or user agent) can select a preferred representation and
redirect its request to that location.
Unless it was a HEAD request, the response SHOULD include an entity
containing a list of resource characteristics and location(s) from
which the user or user agent can choose the one most appropriate. The
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
performed automatically. However, this specification does not define
any standard for such automatic selection.
If the server has a preferred choice of representation, it SHOULD
include the specific URL for that representation in the Location
field; user agents MAY use the Location field value for automatic
redirection. This response is cachable unless indicated otherwise.
10.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any
future references to this resource SHOULD be done using one of the
returned URIs. Clients with link editing capabilities SHOULD
automatically re-link references to the Request-URI to one or more of
the new references returned by the server, where possible. This
response is cachable unless indicated otherwise.
If the new URI is a location, its URL SHOULD be given by the Location
field in the response. Unless the request method was HEAD, the entity
of the response SHOULD contain a short hypertext note with a
hyperlink to the new URI(s).
If the 301 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after receiving
a 301 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.
Fielding, et. al. Standards Track [Page 57]
RFC 2068 HTTP/1.1 January 1997
10.3.3 302 Moved Temporarily
The requested resource resides temporarily under a different URI.
Since the redirection may be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests. This response is
only cachable if indicated by a Cache-Control or Expires header
field.
If the new URI is a location, its URL SHOULD be given by the Location
field in the response. Unless the request method was HEAD, the entity
of the response SHOULD contain a short hypertext note with a
hyperlink to the new URI(s).
If the 302 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after receiving
a 302 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.
10.3.4 303 See Other
The response to the request can be found under a different URI and
SHOULD be retrieved using a GET method on that resource. This method
exists primarily to allow the output of a POST-activated script to
redirect the user agent to a selected resource. The new URI is not a
substitute reference for the originally requested resource. The 303
response is not cachable, but the response to the second (redirected)
request MAY be cachable.
If the new URI is a location, its URL SHOULD be given by the Location
field in the response. Unless the request method was HEAD, the entity
of the response SHOULD contain a short hypertext note with a
hyperlink to the new URI(s).
10.3.5 304 Not Modified
If the client has performed a conditional GET request and access is
allowed, but the document has not been modified, the server SHOULD
respond with this status code. The response MUST NOT contain a
message-body.
Fielding, et. al. Standards Track [Page 58]
RFC 2068 HTTP/1.1 January 1997
The response MUST include the following header fields:
o Date
o ETag and/or Content-Location, if the header would have been sent in
a 200 response to the same request
o Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same variant
If the conditional GET used a strong cache validator (see section
13.3.3), the response SHOULD NOT include other entity-headers.
Otherwise (i.e., the conditional GET used a weak validator), the
response MUST NOT include other entity-headers; this prevents
inconsistencies between cached entity-bodies and updated headers.
If a 304 response indicates an entity not currently cached, then the
cache MUST disregard the response and repeat the request without the
conditional.
If a cache uses a received 304 response to update a cache entry, the
cache MUST update the entry to reflect any new field values given in
the response.
The 304 response MUST NOT include a message-body, and thus is always
terminated by the first empty line after the header fields.
10.3.6 305 Use Proxy
The requested resource MUST be accessed through the proxy given by
the Location field. The Location field gives the URL of the proxy.
The recipient is expected to repeat the request via the proxy.
10.4 Client Error 4xx
The 4xx class of status code is intended for cases in which the
client seems to have erred. Except when responding to a HEAD request,
the server SHOULD include an entity containing an explanation of the
error situation, and whether it is a temporary or permanent
condition. These status codes are applicable to any request method.
User agents SHOULD display any included entity to the user.
Note: If the client is sending data, a server implementation using
TCP should be careful to ensure that the client acknowledges
receipt of the packet(s) containing the response, before the server
closes the input connection. If the client continues sending data
to the server after the close, the server's TCP stack will send a
reset packet to the client, which may erase the client's
Fielding, et. al. Standards Track [Page 59]
RFC 2068 HTTP/1.1 January 1997
unacknowledged input buffers before they can be read and
interpreted by the HTTP application.
10.4.1 400 Bad Request
The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.
10.4.2 401 Unauthorized
The request requires 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
request with a suitable Authorization header field (section 14.8). If
the request already included Authorization credentials, then the 401
response indicates that authorization has been refused for those
credentials. If the 401 response contains the same challenge as the
prior response, and the user agent has already attempted
authentication at least once, then the user SHOULD be presented the
entity that was given in the response, since that entity MAY include
relevant diagnostic information. HTTP access authentication is
explained in section 11.
10.4.3 402 Payment Required
This code is reserved for future use.
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help and the request SHOULD NOT be repeated.
If the request method was not HEAD and the server wishes to make
public why the request has not been fulfilled, it SHOULD describe the
reason for the refusal in the entity. This status code is commonly
used when the server does not wish to reveal exactly why the request
has been refused, or when no other response is applicable.
10.4.5 404 Not Found
The server has not found anything matching the Request-URI. No
indication is given of whether the condition is temporary or
permanent.
Fielding, et. al. Standards Track [Page 60]
RFC 2068 HTTP/1.1 January 1997
If the server does not wish to make this information available to the
client, the status code 403 (Forbidden) can be used instead. The 410
(Gone) status code SHOULD be used if the server knows, through some
internally configurable mechanism, that an old resource is
permanently unavailable and has no forwarding address.
10.4.6 405 Method Not Allowed
The method specified in the Request-Line is not allowed for the
resource identified by the Request-URI. The response MUST include an
Allow header containing a list of valid methods for the requested
resource.
10.4.7 406 Not Acceptable
The resource identified by the request is only capable of generating
response entities which have content characteristics not acceptable
according to the accept headers sent in the request.
Unless it was a HEAD request, the response SHOULD include an entity
containing a list of available entity characteristics and location(s)
from which the user or user agent can choose the one most
appropriate. The 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 performed automatically. However, this specification
does not define any standard for such automatic selection.
Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the request.
In some cases, this may even be preferable to sending a 406
response. User agents are encouraged to inspect the headers of an
incoming response to determine if it is acceptable. If the response
could be unacceptable, a user agent SHOULD temporarily stop receipt
of more data and query the user for a decision on further actions.
10.4.8 407 Proxy Authentication Required
This code is similar to 401 (Unauthorized), but indicates that the
client MUST first authenticate itself with the proxy. The proxy MUST
return a Proxy-Authenticate header field (section 14.33) containing a
challenge applicable to the proxy for the requested resource. The
client MAY repeat the request with a suitable Proxy-Authorization
header field (section 14.34). HTTP access authentication is explained
in section 11.
Fielding, et. al. Standards Track [Page 61]
RFC 2068 HTTP/1.1 January 1997
10.4.9 408 Request Timeout
The client did not produce a request within the time that the server
was prepared to wait. The client MAY repeat the request without
modifications at any later time.
10.4.10 409 Conflict
The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict
and resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem; however, that may not be
possible and is not required.
Conflicts are most likely to occur in response to a PUT request. If
versioning is being used and the entity being PUT includes changes to
a resource which conflict with those made by an earlier (third-party)
request, the server MAY use the 409 response to indicate that it
can't complete the request. In this case, the response entity SHOULD
contain a list of the differences between the two versions in a
format defined by the response Content-Type.
10.4.11 410 Gone
The requested resource is no longer available at the server and no
forwarding address is known. This condition SHOULD be considered
permanent. Clients with link editing capabilities SHOULD delete
references to the Request-URI after user approval. If the server does
not know, or has no facility to determine, whether or not the
condition is permanent, the status code 404 (Not Found) SHOULD be
used instead. This response is cachable unless indicated otherwise.
The 410 response is primarily intended to assist the task of web
maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common for
limited-time, promotional services and for resources belonging to
individuals no longer working at the server's site. It is not
necessary to mark all permanently unavailable resources as "gone" or
to keep the mark for any length of time -- that is left to the
discretion of the server owner.
Fielding, et. al. Standards Track [Page 62]
RFC 2068 HTTP/1.1 January 1997
10.4.12 411 Length Required
The server refuses to accept the request without a defined Content-
Length. The client MAY repeat the request if it adds a valid
Content-Length header field containing the length of the message-body
in the request message.
10.4.13 412 Precondition Failed
The precondition given in one or more of the request-header fields
evaluated to false when it was tested on the server. This 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.
10.4.14 413 Request Entity Too Large
The server is refusing to process a request because the request
entity is larger than the server is willing or able to process. The
server may close the connection to prevent the client from continuing
the request.
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.
10.4.15 414 Request-URI Too Long
The server is refusing to service the request because the Request-URI
is longer than the server is willing to interpret. This rare
condition is only likely to occur when a client has improperly
converted a POST request to a GET request with long query
information, when the client has descended into a URL "black hole" of
redirection (e.g., a redirected URL prefix that points to a suffix of
itself), or when the server is under attack by a client attempting to
exploit security holes present in some servers using fixed-length
buffers for reading or manipulating the Request-URI.
10.4.16 415 Unsupported Media Type
The server is refusing to service the request because the entity of
the request is in a format not supported by the requested resource
for the requested method.
Fielding, et. al. Standards Track [Page 63]
RFC 2068 HTTP/1.1 January 1997
10.5 Server Error 5xx
Response status codes beginning with the digit "5" indicate cases in
which the server is aware that it has erred or is incapable of
performing the request. Except when responding to a HEAD request, the
server SHOULD include an entity containing an explanation of the
error situation, and whether it is a temporary or permanent
condition. User agents SHOULD display any included entity to the
user. These response codes are applicable to any request method.
10.5.1 500 Internal Server Error
The server encountered an unexpected condition which prevented it
from fulfilling the request.
10.5.2 501 Not Implemented
The server does not support the functionality required to fulfill the
request. This is the appropriate response when the server does not
recognize the request method and is not capable of supporting it for
any resource.
10.5.3 502 Bad Gateway
The server, while acting as a gateway or proxy, received an invalid
response from the upstream server it accessed in attempting to
fulfill the request.
10.5.4 503 Service Unavailable
The server is currently unable to handle the request due to a
temporary overloading or maintenance of the server. The implication
is that this is a temporary condition which will be alleviated after
some delay. If known, the length of the delay may be indicated in a
Retry-After header. If no Retry-After is given, the client SHOULD
handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers may wish
to simply refuse the connection.
10.5.5 504 Gateway Timeout
The server, while acting as a gateway or proxy, did not receive a
timely response from the upstream server it accessed in attempting to
complete the request.
Fielding, et. al. Standards Track [Page 64]
RFC 2068 HTTP/1.1 January 1997
10.5.6 505 HTTP Version Not Supported
The server does not support, or refuses to support, the HTTP protocol
version that was used in the request message. The server is
indicating that it is unable or unwilling to complete the request
using the same major version as the client, as described in section
3.1, other than with this error message. The response SHOULD contain
an entity describing why that version is not supported and what other
protocols are supported by that server.
11 Access Authentication
HTTP provides a simple challenge-response authentication mechanism
which MAY be used by a server to challenge a client request and by a
client to provide authentication information. It uses an extensible,
case-insensitive token to identify the authentication scheme,
followed by a comma-separated list of attribute-value pairs which
carry the parameters necessary for achieving authentication via that
scheme.
auth-scheme = token
auth-param = token "=" quoted-string
The 401 (Unauthorized) response message is used by an origin server
to challenge the authorization of a user agent. This response MUST
include a WWW-Authenticate header field containing at least one
challenge applicable to the requested resource.
challenge = auth-scheme 1*SP realm *( "," auth-param )
realm = "realm" "=" realm-value
realm-value = quoted-string
The realm attribute (case-insensitive) is required for all
authentication schemes which issue a challenge. The realm value
(case-sensitive), in combination with the canonical root URL (see
section 5.1.2) of the server being accessed, defines the protection
space. These realms allow the protected resources on a server to be
partitioned into a set of protection spaces, each with its own
authentication scheme and/or authorization database. The realm value
is a string, generally assigned by the origin server, which may have
additional semantics specific to the authentication scheme.
A user agent that wishes to authenticate itself with a server--
usually, but not necessarily, after 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
Fielding, et. al. Standards Track [Page 65]
RFC 2068 HTTP/1.1 January 1997
containing the authentication information of the user agent for the
realm of the resource being requested.
credentials = basic-credentials
| auth-scheme #auth-param
The domain over which credentials can be automatically applied by a
user agent is determined by the protection space. If a prior request
has been authorized, the same credentials MAY be reused for all other
requests within that protection space for a period of time determined
by the authentication scheme, parameters, and/or user preference.
Unless otherwise defined by the authentication scheme, a single
protection space cannot extend outside the scope of its server.
If the server does not wish to accept the credentials sent with a
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
explaining the refusal.
The HTTP protocol does not restrict applications to this simple
challenge-response mechanism for access authentication. Additional
mechanisms MAY be used, such as encryption at the transport level or
via message encapsulation, and with additional header fields
specifying authentication information. However, these additional
mechanisms are not defined by this specification.
Proxies MUST be completely transparent regarding user agent
authentication. That is, they MUST forward the WWW-Authenticate and
Authorization headers untouched, and follow the rules found in
section 14.8.
HTTP/1.1 allows a client to pass authentication information to and
from a proxy via the Proxy-Authenticate and Proxy-Authorization
headers.
11.1 Basic Authentication Scheme
The "basic" authentication scheme is based on the model that the user
agent must authenticate itself with a user-ID and a password for each
realm. The realm value should be considered an opaque string which
can only be compared for equality with other realms on that server.
The server will service the request only if it can validate the
user-ID and password for the protection space of the Request-URI.
There are no optional authentication parameters.
Fielding, et. al. Standards Track [Page 66]
RFC 2068 HTTP/1.1 January 1997
Upon receipt of an unauthorized request for a URI within the
protection space, the server MAY respond with a challenge like the
following:
WWW-Authenticate: Basic realm="WallyWorld"
where "WallyWorld" is the string assigned by the server to identify
the protection space of the Request-URI.
To receive authorization, the client sends the userid and password,
separated by a single colon (":") character, within a base64 encoded
string in the credentials.
basic-credentials = "Basic" SP basic-cookie
basic-cookie = <base64 [7] encoding of user-pass,
except not limited to 76 char/line>
user-pass = userid ":" password
userid = *<TEXT excluding ":">
password = *TEXT
Userids might be case sensitive.
If the user agent wishes to send the userid "Aladdin" and password
"open sesame", it would use the following header field:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
See section 15 for security considerations associated with Basic
authentication.
11.2 Digest Authentication Scheme
A digest authentication for HTTP is specified in RFC 2069 [32].
12 Content Negotiation
Most HTTP responses include an entity which contains information for
interpretation by a human user. Naturally, it is desirable to supply
the user with the "best available" entity corresponding to the
request. Unfortunately for servers and caches, not all users have
the same preferences for what is "best," and not all user agents are
equally capable of rendering all entity types. For that reason, HTTP
has provisions for several mechanisms for "content negotiation" --
the process of selecting the best representation for a given response
Fielding, et. al. Standards Track [Page 67]
RFC 2068 HTTP/1.1 January 1997
when there are multiple representations available.
Note: This is not called "format negotiation" because the alternate
representations may be of the same media type, but use different
capabilities of that type, be in different languages, etc.
Any response containing an entity-body MAY be subject to negotiation,
including error responses.
There are two kinds of content negotiation which are possible in
HTTP: server-driven and agent-driven negotiation. These two kinds of
negotiation are orthogonal and thus may be used separately or in
combination. One method of combination, referred to as transparent
negotiation, occurs when a cache uses the agent-driven negotiation
information provided by the origin server in order to provide
server-driven negotiation for subsequent requests.
12.1 Server-driven Negotiation
If the selection of the best representation for a response is made by
an algorithm located at the server, it is called server-driven
negotiation. Selection is based on the available representations of
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
(such as the network address of the client).
Server-driven negotiation is advantageous when the algorithm for
selecting from among the available representations is difficult to
describe to the user agent, or when the server desires to send its
"best guess" to the client along with the first response (hoping to
avoid the round-trip delay of a subsequent request if the "best
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, etc.) which describe its
preferences for such a response.
Server-driven negotiation has disadvantages:
1. It is impossible for the server to accurately determine what might be
"best" for any given user, since that would require complete
knowledge of both the capabilities of the user agent and the intended
use for the response (e.g., does the user want to view it on screen
or print it on paper?).
2. Having the user agent describe its capabilities in every request can
be both very inefficient (given that only a small percentage of
responses have multiple representations) and a potential violation of
Fielding, et. al. Standards Track [Page 68]
RFC 2068 HTTP/1.1 January 1997
the user's privacy.
3. It complicates the implementation of an origin server and the
algorithms for generating responses to a request.
4. It may limit a public cache's ability to use the same response for
multiple user's requests.
HTTP/1.1 includes the following request-header fields for enabling
server-driven negotiation through description of user agent
capabilities and user preferences: Accept (section 14.1), Accept-
Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
Language (section 14.4), and User-Agent (section 14.42). However, an
origin server is not limited to these dimensions and MAY vary the
response based on any aspect of the request, including information
outside the request-header fields or within extension header fields
not defined by this specification.
HTTP/1.1 origin servers MUST include an appropriate Vary header field
(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
representations).
HTTP/1.1 public caches MUST recognize the Vary header field when it
is included in a response and obey the requirements described in
section 13.6 that describes the interactions between caching and
content negotiation.
12.2 Agent-driven Negotiation
With agent-driven negotiation, selection of the best representation
for a response is performed by the user agent after receiving an
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-body of the initial
response, with each representation identified by its own URI.
Selection from among the representations may be performed
automatically (if the user agent is capable of doing so) or manually
by the user selecting from a generated (possibly hypertext) menu.
Agent-driven negotiation is advantageous when the response would vary
over commonly-used dimensions (such as type, language, or encoding),
when the origin server is unable to determine a user agent's
capabilities from examining the request, and generally when public
caches are used to distribute server load and reduce network usage.
Fielding, et. al. Standards Track [Page 69]
RFC 2068 HTTP/1.1 January 1997
Agent-driven negotiation suffers from the disadvantage of needing a
second request to obtain the best alternate representation. This
second request is only efficient when caching is used. In addition,
this specification does not define any mechanism for supporting
automatic selection, though it also does not prevent any such
mechanism from being developed as an extension and used within
HTTP/1.1.
HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
status codes for enabling agent-driven negotiation when the server is
unwilling or unable to provide a varying response using server-driven
negotiation.
12.3 Transparent Negotiation
Transparent negotiation is a combination of both server-driven and
agent-driven negotiation. When a cache is supplied with a form of the
list of available representations of the response (as in agent-driven
negotiation) and the dimensions of variance are completely understood
by the cache, then the cache becomes capable of performing server-
driven negotiation on behalf of the origin server for subsequent
requests on that resource.
Transparent negotiation has the advantage of distributing the
negotiation work that would otherwise be required of the origin
server and also removing the second request delay of agent-driven
negotiation when the cache is able to correctly guess the right
response.
This specification does not define any mechanism for transparent
negotiation, though it also does not prevent any such mechanism from
being developed as an extension and used within HTTP/1.1. An HTTP/1.1
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
clients. The agent-driven negotiation information supplied by the
origin server SHOULD be included with the transparently negotiated
response.
13 Caching in HTTP
HTTP is typically used for distributed information systems, where
performance can be improved by the use of response caches. The
HTTP/1.1 protocol includes a number of elements intended to make
caching work as well as possible. Because these elements are
inextricable from other aspects of the protocol, and because they
interact with each other, it is useful to describe the basic caching
design of HTTP separately from the detailed descriptions of methods,
Fielding, et. al. Standards Track [Page 70]
RFC 2068 HTTP/1.1 January 1997
headers, response codes, etc.
Caching would be useless if it did not significantly improve
performance. The goal of caching in HTTP/1.1 is to eliminate the need
to send requests in many cases, and to eliminate the need to send
full responses in many other cases. The former reduces the number of
network round-trips required for many operations; we use an
"expiration" mechanism for this purpose (see section 13.2). The
latter reduces network bandwidth requirements; we use a "validation"
mechanism for this purpose (see section 13.3).
Requirements for performance, availability, and disconnected
operation require us to be able to relax the goal of semantic
transparency. The HTTP/1.1 protocol allows origin servers, caches,
and clients to explicitly reduce transparency when necessary.
However, because non-transparent operation may confuse non-expert
users, and may be incompatible with certain server applications (such
as those for ordering merchandise), the protocol requires that
transparency be relaxed
o only by an explicit protocol-level request when relaxed by client
or origin server
o only with an explicit warning to the end user when relaxed by cache
or client
谁翻译了请给我发一份 xzjxu@126.com
