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
client
Click on the red underlined text to get to the source
... content
negotiation.
client
A program that establishes connections for the purpose of sending
...
... user agent
The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.
...
... service requests by sending back responses. Any given program may
be capable of being both a client and a server; our use of these
terms refers only to the role being performed by the program for a
...
... proxy
An intermediary program which acts as both a server and a client
for the purpose of making requests on behalf of other clients.
...
... An intermediary program which acts as both a server and a client
for the purpose of making requests on behalf of other clients.
Requests are serviced internally or by passing them on, with
possible translation, to other servers. A proxy ...
... possible translation, to other servers. A proxy must implement
both the client and server requirements of this specification.
...
... proxy, a gateway receives requests as if it were the
origin server for the requested resource; the requesting client
may not be aware that it is communicating with a gateway.
...
... time and network bandwidth consumption on future, equivalent
requests. Any client or server may include a cache, though a cache
...
... cache behaves in a "semantically transparent" manner, with
respect to a particular response, when its use affects neither the
requesting client nor the origin server, except to improve
performance. When a cache ...
... performance. When a cache is semantically transparent, the client
receives exactly the same response (except for hop-by-hop headers)
...
... The HTTP protocol is a request/response protocol. A client sends a
request to the server in the form of a request method, URI ...
... version, followed by a MIME-like message containing request
modifiers, client information, and possible body content over a
connection with a server. The server responds with a status line,
...
... may be engaged in multiple, simultaneous communications. For example,
B may be receiving requests from many clients other than A, and/or
forwarding requests to servers other than C, at the same time that it
is handling A's request.
...
... URI lengths
above 255 bytes, because some older client or proxy implementations
may not properly support these lengths.
...
...
When comparing two URIs to decide if they match or not, a client
SHOULD use a case-sensitive octet-by-octet comparison of the entire
...
... 12] date format and lacks a four-digit year.
HTTP/1.1 clients and servers that parse the date value MUST accept
all three formats (for compatibility with HTTP/1.0 ...
... date/time stamp format apply only
to their usage within the protocol stream. Clients and servers are
not required to use these formats for user presentation, request
logging, etc.
...
... tokens should be registered; to allow
interoperability between clients and servers, specifications of the
content coding algorithms needed to implement a new value should be
...
...
Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter. HTTP/1.1 ...
...
HTTP messages consist of requests from client to server and responses
from server to client.
...
... HTTP messages consist of requests from client to server and responses
from server to client.
HTTP ...
...
Note: certain buggy HTTP/1.0 client implementations generate an
extra CRLF's after a POST request. To restate what is explicitly
...
... forbidden by the BNF, an HTTP/1.1 client must not preface or follow
a request with an extra CRLF.
...
... header with multiple byte-range
specifiers implies that the client can parse multipart/byteranges
responses.
...
...
A request message from a client to a server includes, within the
first line of that message, the method to be applied to the resource,
...
... header field (section 14.7). The return code of the response
always notifies the client whether a method is currently allowed on a
resource, since the set of allowed methods ...
... HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies.
...
... be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would
create ...
...
The request-header fields allow the client to pass additional
information about the request, and about the client itself, to the
...
... request-header fields allow the client to pass additional
information about the request, and about the client itself, to the
server. These fields act as request modifiers, with semantics
...
... textual description of the Status-Code. The Status-Code is intended
for use by automata and the Reason-Phrase is intended for the human
user. The client is not required to examine or display the Reason-
Phrase.
...
... complete the request
o 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled
...
... unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code ...
...
In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity.
...
... Internet. The use of inline images and
other associated data often requires a client to make multiple
requests of the same server in a short amount of time. Analyses of
these performance ...
... connection.
Pipelining allows a client to make multiple requests without
waiting for each response, allowing a single TCP connection to be
...
... HTTP can evolve more gracefully; since errors can be reported
without the penalty of closing the TCP connection. Clients using
future versions of HTTP ...
... HTTP connection. That is, unless otherwise indicated, the client may
assume that the server will maintain a persistent connection.
...
...
Persistent connections provide a mechanism by which a client and a
server can signal the close of a TCP connection. This signaling ...
... Connection header field. Once a close has been
signaled, the client MUST not send any more requests on that
connection.
...
... An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
maintain a persistent connection unless a Connection ...
...
An HTTP/1.1 client MAY expect a connection to remain open, but would
decide to keep it open based on whether the response from a server
...
... connection-token close. In case
the client does not want to maintain a connection for more than that
request, it SHOULD send a Connection ...
... connection.
Clients and servers SHOULD NOT assume that a persistent connection is
maintained for HTTP ...
... signaled. See section 19.7.1 for more information on backwards
compatibility with HTTP/1.0 clients.
In order to remain persistent, all messages on the connection ...
...
A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each
...
... same order that the requests were received.
Clients which assume persistent connections and pipeline immediately
after connection establishment ...
... connection establishment SHOULD be prepared to retry their
connection if the first pipelined attempt fails. If a client does
such a retry, it MUST NOT pipeline before it knows the connection is
...
... such a retry, it MUST NOT pipeline before it knows the connection is
persistent. Clients MUST also be prepared to resend their requests if
the server closes the connection before sending all of the
...
... proxy server MUST signal persistent connections separately with
its clients and the origin servers (or other proxy servers) that it
connects to. Each persistent connection ...
... connection. Proxy servers might make
this a higher value since it is likely that the client will be making
more connections through the same server. The use of persistent
...
... connections places no requirements on the length of this time-out for
either the client or the server.
When a client or server ...
... client or the server.
When a client or server wishes to time-out it SHOULD issue a graceful
close on the transport connection. Clients and servers ...
... client or server wishes to time-out it SHOULD issue a graceful
close on the transport connection. Clients and servers SHOULD both
constantly watch for the other side of the transport close, and
...
... constantly watch for the other side of the transport close, and
respond to it as appropriate. If a client or server does not detect
the other side's close promptly it could cause unnecessary resource
drain on the network ...
... proxy MAY close the transport connection at any
time. For example, a client MAY have started to send a new request at
the same time that the server has decided to close the "idle"
connection ...
... connection. From the server's point of view, the connection is being
closed while it was idle, but from the client's point of view, a
request is in progress.
...
... request is in progress.
This means that clients, servers, and proxies MUST be able to recover
from asynchronous ...
... proxies MUST be able to recover
from asynchronous close events. Client software SHOULD reopen the
transport connection and retransmit the aborted request without user
...
... is suspected.
Clients that use persistent connections SHOULD limit the number of
simultaneous connections ...
... simultaneous connections that they maintain to a given server. A
single-user client SHOULD maintain AT MOST 2 connections with any
server or proxy ...
... rather than terminating connections with the expectation that
clients will retry. The latter technique can exacerbate network
congestion ...
...
o An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
the network connection ...
... error status while it is transmitting
the request. If the client sees an error status, it SHOULD
immediately cease transmitting ...
...
o An HTTP/1.1 (or later) client MUST be prepared to accept a 100
(Continue) status followed by a regular response.
...
... HTTP/1.1 (or later) server that receives a request from a
HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue)
response; it SHOULD either wait for the request to be completed
normally (thus avoiding an interrupted request) or close the
...
... requirements from an
HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
respond with 100 (Continue) status and continue to read from the
...
... error status.
Clients SHOULD remember the version number of at least the most
recently used server; if an HTTP/1.1 ...
... version number of at least the most
recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or
later response from the server, and it sees the connection ...
... connection close
before receiving any status from the server, the client SHOULD retry
the request without user interaction so long as the request method is
...
... automatically retried, although user agents MAY offer a human
operator the choice of retrying the request.. If the client does
retry the request, the client
...
... operator the choice of retrying the request.. If the client does
retry the request, the client
o MUST first send the request header fields ...
...
o MUST wait for the server to respond with either a 100 (Continue)
response, in which case the client should continue, or with an
error status.
...
...
If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
the server, it should assume that the server implements HTTP/1.0 ...
... HTTP/1.0 or
older and will not use the 100 (Continue) response. If in this case
the client sees the connection close before receiving any status from
...
... connection close before receiving any status from
the server, the client SHOULD retry the request. If the client does
retry the request to this HTTP/1.0 ...
... receiving any status from
the server, the client SHOULD retry the request. If the client does
retry the request to this HTTP/1.0 server, it should use the
...
... of the request.
7. If client sees that the connection is closed prematurely, repeat
from step 1 until the request is accepted, an error response ...
... methods cannot be assumed to
share the same semantics for separately extended clients and servers.
The Host ...
... identified by the Request-URI. This method allows the client to
determine the options and/or requirements associated with a resource,
...
... network
usage by allowing cached entities to be refreshed without requiring
multiple requests or transferring data already held by the client.
The semantics ...
... network usage by allowing partially-retrieved entities to be
completed without transferring data already held by the client.
The response to a GET request is cachable if and only if it meets the
...
... Request-URI. This method MAY be overridden by human
intervention (or other means) on the origin server. The client cannot
be guaranteed that the operation has been carried out, even if the
status code ...
... back of the request message. The final recipient of the request
SHOULD reflect the message received back to the client as the
entity-body of a 200 (OK) response. The final recipient is either the
...
...
TRACE allows the 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 ...
... 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
proxies ...
... status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
client except under experimental conditions.
...
...
The client may continue with its request. This interim response is
used to inform the client that the initial part of the request has
...
... The client may continue with its request. This interim response is
used to inform the client that the initial part of the request has
been received and has not yet been rejected by the server. The client ...
... client that the initial part of the request has
been received and has not yet been rejected by the server. The client
SHOULD continue by sending the remainder of the request or, if the
request has already been completed, ignore this response. The server
...
...
The server understands and is willing to comply with the client's
request, via the Upgrade message header field (section 14.41), for a
...
... This class of status code indicates that the client's request was
successfully received, understood, and accepted.
...
...
The server has fulfilled the request but there is no new information
to send back. If the client is a user agent, it SHOULD NOT change its
document view from that which caused the request to be sent. This
...
... future references to this resource SHOULD be done using one of the
returned URIs. Clients with link editing capabilities SHOULD
automatically re-link ...
... 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
...
...
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 ...
... Client Error 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 ...
... entity to the user.
Note: If the client is sending data, a server implementation using
TCP should be careful to ensure that the client ...
... 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 ...
... 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
...
... 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
...
... TCP stack will send a
reset packet to the client, which may erase the client's
unacknowledged input buffers ...
... The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.
...
... 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 ...
...
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 ...
...
This code is similar to 401 (Unauthorized), but indicates that the
client MUST first authenticate itself with the proxy. The proxy ...
... challenge applicable to the proxy for the requested resource. The
client MAY repeat the request with a suitable Proxy-Authorization
...
...
The client did not produce a request within the time that the server
was prepared to wait. The client MAY repeat the request without
...
... 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.
...
... forwarding address is known. This condition SHOULD be considered
permanent. Clients with link editing capabilities SHOULD delete
...
...
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 ...
... 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
...
... 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.
...
... After header field to indicate that it is temporary and after what
time the client may try again.
...
... 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
...
... converted a POST request to a GET request with long query
information, when the client has descended into a URL "black hole" of
...
... 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
...
... Retry-After header. If no Retry-After is given, the client SHOULD
handle the response as it would for a 500 response.
...
... 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
...
... challenge-response authentication mechanism
which MAY be used by a server to challenge a client request and by a
client to provide authentication information ...
... 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 ...
...
To receive authorization, the client sends the userid and password,
separated by a single colon (":") character, within a base64 ...
... 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
...
... is cachable to ensure correct interoperation with all HTTP/1.1
clients. The agent-driven negotiation information supplied by 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
...
... 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
Therefore, the HTTP/1.1 ...
... semantic transparency.
A basic principle is that it must be possible for the clients to
detect any potential relaxation of semantic transparency.
...
...
Note: The server, cache, or client implementer may be faced with
design decisions not explicitly discussed in this specification. If
...
... means it meets the least restrictive freshness requirement of the
client, server, and cache (see section 14.9); if the origin server
so specifies, it is the freshness requirement ...
... alone.
3. It includes a warning if the freshness demand of the client or the
origin server is violated (see section 13.1.5 and 14.45).
...
... cache receives a response (either an entire response, or a 304
(Not Modified) response) that it would normally forward to the
requesting client, and the received response is no longer fresh, the
cache SHOULD forward it to the requesting client ...
... client, and the received response is no longer fresh, the
cache SHOULD forward it to the requesting client without adding a new
Warning (but without removing any existing Warning headers ...
... must attach a warning to that effect, using a Warning response-
header. This warning allows clients to take appropriate action.
Warnings may be used for other purposes, both cache ...
... Warnings are assigned numbers between 0 and 99. This specification
defines the code numbers and meanings of each currently assigned
warnings, allowing a client or cache to take automated action in some
(but not all) cases.
...
... Warnings also carry a warning text. The text may be in any
appropriate natural language (perhaps based on the client's Accept
headers), and include an optional indication of what character set ...
... times and validators) are implicit directives to caches. In some
cases, a server or client may need to provide explicit directives to
the HTTP caches ...
... The Cache-Control header allows a client or server to transmit a
variety of directives in either requests or responses. These
directives typically override the default caching algorithms ...
... In some cases, the operator of a cache may choose to configure it to
return stale responses even when not requested by clients. This
decision should not be made lightly, but may be necessary for reasons
of availability or performance ...
... response, it MUST mark it as such (using a Warning header). This
allows the client software to alert the user that there may be a
potential problem.
...
... fresh response. For this reason, a cache SHOULD NOT return a stale
response if the client explicitly requests a first-hand or fresh one,
unless it is impossible to comply for technical or policy reasons.
...
... Client-controlled Behavior ...
... caches,
by their contribution to the age of a response) are the primary
source of expiration information, in some cases the client may need
to control a cache's decision about whether to return a cached
...
... to control a cache's decision about whether to return a cached
response without validating it. Clients do this using several
directives of the Cache-Control header ...
... header.
A client's request may specify the maximum age it is willing to
accept of an unvalidated response; specifying a value of zero forces
...
... forces
the cache(s) to revalidate all responses. A client may also specify
the minimum time remaining before a response expires. Both of these
options increase constraints ...
... semantic transparency.
A client may also specify that it will accept stale responses, up to
some maximum amount of staleness. This loosens the constraints on the
...
... cache
and not to first-hand responses forwarded immediately to the
requesting client.
If an origin server wishes to force a semantically transparent cache ...
... from the time that a server generates a response and the time it is
received at the next outbound cache or client. If uncorrected, this
delay could result in improperly low ages.
...
... cache.
Note that a client cannot reliably tell that a response is first-
hand, but the presence of an Age header indicates that a response
...
... header indicates that a response
is definitely not first-hand. Also, if the Date in a response is
earlier than the client's local request time, the response is
probably not first-hand (in the absence of serious clock skew).
...
... different.
If a client performing a retrieval receives a non-first-hand response
for a request that was already fresh in its own cache, and the Date
...
... header in its existing cache entry is newer than the Date on the new
response, then the client MAY ignore the response. If so, it MAY
retry the request with a "Cache-Control: max-age=0" directive (see
...
... cache is pooling
responses from other caches, or because a client has asked for a
reload or a revalidation of an apparently fresh cache entry.
...
... responses flow through a different set of caches, a client may
receive responses in an order different from that in which the origin
server sent them. We would like the client ...
... client may
receive responses in an order different from that in which the origin
server sent them. We would like the client to use the most recently
generated response, even if older responses are still apparently
fresh.
...
... one second.
When a client tries to revalidate a cache entry, and the response it
receives contains a Date header ...
... receives contains a Date header that appears to be older than the one
for the existing entry, then the client SHOULD repeat the request
unconditionally, and include
...
... server.
If the Date values are equal, then the client may use either response
(or may, if it is being extremely prudent, request a new response).
Servers MUST NOT depend on clients ...
... client may use either response
(or may, if it is being extremely prudent, request a new response).
Servers MUST NOT depend on clients being able to choose
deterministically between responses generated during the same second,
if their expiration times overlap.
...
... When a cache has a stale entry that it would like to use as a
response to a client's request, it first has to check with the origin
server (or possibly an intermediate cache with a fresh response) to
...
... generates a full response, it attaches some sort of validator to it,
which is kept with the cache entry. When a client (user agent or
proxy ...
... is likely "good enough" to be equivalent.
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
...
... entity. However, only a strong validator is usable for a sub-range
retrieval, since otherwise the client may end up with an internally
inconsistent entity.
...
... or
o The validator is about to be used by a client in an If-Modified-
Since or If-Unmodified-Since header, because the client ...
... client in an If-Modified-
Since or If-Unmodified-Since header, because the client has a cache
entry for the associated entity ...
... believed that 60 seconds is too short.
If a client wishes to perform a sub-range retrieval on a value for
which it has only a Last-Modified time and no opaque ...
... These rules allow HTTP/1.1 caches and clients to safely perform sub-
range retrievals on values that have been obtained from HTTP/1.0 ...
...
We adopt a set of rules and recommendations for origin servers,
clients, and caches regarding when various validator types should be
used, and for what purposes.
...
... cache, upon receiving a request, MUST use the most
restrictive validator when deciding whether the client's cache entry
matches the cache ...
... A note on rationale: The general principle behind these rules is
that HTTP/1.1 servers and clients should transmit as much non-
redundant information as is available in their responses and
requests. HTTP/1.1 ...
... caches may violate this expectation (for example, when little
or no network connectivity is available). A client can usually detect
that such a response was taken from a cache by comparing the Date
...
... provides a 304 (Not Modified) response, the cache must construct a
response to send to the requesting client. The cache uses the
entity ...
... update the header fields of the
existing entry, and the result MUST be returned to the client.
The Vary header field ...
... 13.5.4; the result might be a full response or might still be
partial. A cache MUST NOT return a partial response to a client
without explicitly marking it as such, using the 206 (Partial
Content) status code ...
... If a cache receives a 5xx response while attempting to revalidate an
entry, it may either forward this response to the requesting client,
or act as if the server failed to respond. In the latter case, it MAY
...
... methods except for GET and HEAD. A cache MUST
NOT reply to such a request from a client before having transmitted
the request to the inbound server, and having received a
corresponding response from the inbound server. This does not prevent
...
... header fields, both sender and
recipient refer to either the client or the server, depending on who
sends and who receives the entity.
...
... If no Accept header field is present, then it is assumed that the
client accepts all media types. If an Accept header field is present,
...
... character sets are acceptable for the response. This field allows
clients capable of understanding more comprehensive or special-
purpose character sets to signal that capability to a server which is
...
... If no Accept-Encoding header is present in a request, the server MAY
assume that the client will accept any content coding. If an Accept-
Encoding header is present, and if the server cannot send a response
...
...
Note: As intelligibility is highly dependent on the individual
user, it is recommended that client applications make the choice of
linguistic preference available to the user. If the choice is not
made available, then the Accept-Language ...
... Ranges: bytes
but are not required to do so. Clients MAY generate byte-range
requests without having received this header ...
... Allow: GET, HEAD, PUT
This field cannot prevent a client from trying other methods.
However, the indications given by the Allow header field ...
... anywhere. This allows an origin server to prevent caching even by
caches that have been configured to return stale responses to client
requests.
Note: Most HTTP/1.0 ...
...
max-age
Indicates that the client is willing to accept a response whose age
is no greater than the specified time in seconds. Unless max-stale
directive is also included, the client ...
... client is willing to accept a response whose age
is no greater than the specified time in seconds. Unless max-stale
directive is also included, the client is not willing to accept a
stale response.
...
...
min-fresh
Indicates that the client is willing to accept a response whose
freshness lifetime is no less than its current age plus the
...
... lifetime is no less than its current age plus the
specified time in seconds. That is, the client wants a response
that will still be fresh for at least the specified number of
seconds.
...
...
max-stale
Indicates that the client is willing to accept a response that has
exceeded its expiration time. If max-stale is assigned a value,
then the client ...
... client is willing to accept a response that has
exceeded its expiration time. If max-stale is assigned a value,
then the client is willing to accept a response that has exceeded
its expiration time by no more than the specified number of
seconds. If no value is assigned to max-stale, then the client ...
... client is willing to accept a response that has exceeded
its expiration time by no more than the specified number of
seconds. If no value is assigned to max-stale, then the client is
willing to accept a stale response of any age.
...
...
End-to-end revalidation may be requested either when the client does
not have its own local cached copy, in which case we call it
"unspecified end-to-end ...
... not have its own local cached copy, in which case we call it
"unspecified end-to-end revalidation", or when the client does have a
local cached copy, in which case we call it "specific end-to-end
...
... revalidation."
The client can specify these three kinds of action using Cache-
Control request directives:
...
... compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field
names may be included with the no-cache ...
... cache is forced, by means of a max-age=0
directive, to revalidate its own cache entry, and the client has
supplied its own validator in the request, the supplied validator may
differ from the validator currently stored with the cache ...
... then the cache should return its now validated copy to the client
with a 200 (OK) response. If the server replies with a new entity ...
... cache validator, however, the intermediate cache should compare the
returned validator with the one provided in the client's request,
using the strong comparison function. If the client ...
... client's request,
using the strong comparison function. If the client's validator is
equal to the origin server's, then the intermediate cache simply
...
... In some cases, such as times of extremely poor network connectivity,
a client may want a cache to return only those responses that it
currently has stored, and not to reload or revalidate with the origin
...
... cache to return only those responses that it
currently has stored, and not to reload or revalidate with the origin
server. To do this, the client may include the only-if-cached
directive in a request. If it receives this directive, a cache SHOULD
...
... Because a cache may be configured to ignore a server's specified
expiration time, and because a client request may include a max-stale
directive (which has a similar effect), the protocol also includes a
mechanism for the origin server to require revalidation of a cache ...
... inserted. It also indicates the total size of the full entity-body.
When a server returns a partial response to a client, it must
describe both the extent of the range covered by the response, and
...
... definition.
A client that cannot decode a MIME multipart/byteranges message
should not ask for multiple byte-ranges ...
... ranges in a single request.
When a client requests multiple byte-ranges in one request, the
server SHOULD return them in the order that they appeared in the
...
... did not exist. (Normally, this means return a 200 response containing
the full entity). The reason is that the only time a client will make
such an invalid request is when the entity is smaller than the entity ...
... origin--is important for evaluating cached responses, origin servers
MUST include a Date header field in all responses. Clients SHOULD
only send a Date header field in messages that include an entity ...
...
HTTP/1.1 clients and caches MUST treat other invalid date formats,
especially including the value "0", as in the past (i.e., "already
...
... used.
Note: The client SHOULD not send the From header field without the
user's approval, as it may conflict with the user's privacy ...
... Note that If-Modified-Since times are interpreted by the server,
whose clock may not be synchronized with the client.
Note that if a client ...
... client.
Note that if a client uses an arbitrary date in the If-Modified-Since
header instead of a date taken from the Last-Modified header ...
... header instead of a date taken from the Last-Modified header for the
same request, the client should be aware of the fact that this date
is interpreted in the server's understanding of time. The client
...
... same request, the client should be aware of the fact that this date
is interpreted in the server's understanding of time. The client
should consider unsynchronized clocks and rounding problems due to
the different encodings ...
... should consider unsynchronized clocks and rounding problems due to
the different encodings of time between the client and server. This
includes the possibility of race conditions if the document has
changed between the time it was first requested and the If-Modified-
...
... Since date of a subsequent request, and the possibility of clock-
skew-related problems if the If-Modified-Since date is derived from
the client's clock without correction to the server's clock.
Corrections for different time bases between client and server are at
...
... the client's clock without correction to the server's clock.
Corrections for different time bases between client and server are at
best approximate due to network latency ...
... request-header field is used with a method to make it
conditional. A client that has one or more entities previously
obtained from the resource can verify that one of those entities is
current by including a list of their associated entity ...
... method, and
MUST return a 412 (Precondition Failed) response. This behavior is
most useful when the client wants to prevent an updating method, such
as PUT, from modifying a resource that has changed since the client ...
... client wants to prevent an updating method, such
as PUT, from modifying a resource that has changed since the client
last retrieved it.
...
... request-header field is used with a method to make
it conditional. A client that has one or more entities previously
obtained from the resource can verify that none of those entities is
current by including a list of their associated entity ...
... 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 ...
... The If-Range header allows a client to "short-circuit" the second
request. Informally, its meaning is `if the entity ...
... 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.
...
... backwards compatibility with
HTTP/1.0. Clients SHOULD include both header fields when a no-cache
...
... connection and SHOULD NOT be passed on to
downstream clients. However, an intermediate proxy may need to obtain
its own credentials ...
... its own credentials by requesting them from the downstream client,
which in some circumstances will appear as if the proxy is forwarding
...
... Proxy-Authorization request-header field allows the client to
identify itself (or its user) to a proxy which requires
...
... proxy MAY
relay the credentials from the client request to the next proxy if
that is the mechanism by which the proxies ...
... This header field applies only to the server directly connected to
the client (i.e., the nearest neighbor in a chain of connections). If
...
... 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.
...
... 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
...
... The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI ...
... may reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the
Referer field is sent. For example, a browser client could have a
toggle switch for browsing openly/anonymously, which would
...
... service is expected to
be unavailable to the requesting client. The value of this field can
be either an HTTP-date or an integer ...
...
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 ...
... 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 ...
... 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
...
... 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.
...
... network address of the client), play a role in the selection of the
response representation. Subsequent requests on that resource can
...
... indicate the intermediate protocols and recipients between the user
agent and the server on requests, and between the origin server and
the client on responses. It is analogous to the "Received" field of
RFC 822std11(-> 2822prop) and is intended to be used for tracking message forwards,
...
... version of the message
received by the server or client along each segment of the
request/response ...
... 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,
...
... Authentication of Clients ...
... connection
mechanism to engage in multiple transactions with the client while
impersonating the original server in a way that is not detectable by
the client.
...
... transactions