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
HTTP
Click on the red underlined text to get to the source
...
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
...
... application-level
protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World-Wide Web global
information initiative since 1990. The first version of HTTP ...
... HTTP has been in use by the World-Wide Web global
information initiative since 1990. The first version of HTTP,
referred to as HTTP/0.9, was a simple protocol for raw data transfer ...
... version of HTTP,
referred to as HTTP/0.9, was a simple protocol for raw data transfer
across the Internet ...
... modifiers on the request/response semantics. However, HTTP/1.0 does
not sufficiently take into consideration the effects of hierarchical
proxies ...
... connections, and virtual
hosts. In addition, the proliferation of incompletely-implemented
applications calling themselves "HTTP/1.0" has necessitated a
protocol version change in order for two communicating applications
...
... to determine each other's true capabilities.
This specification defines the protocol referred to as "HTTP/1.1".
This protocol includes more stringent requirements than HTTP/1.0 ...
... HTTP/1.1".
This protocol includes more stringent requirements than HTTP/1.0 in
order to ensure reliable implementation of its features.
...
... MIME).
HTTP is also used as a generic protocol for communication between
user agents and proxies ...
... 2],
and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
access to resources available from diverse applications.
...
... This specification uses a number of terms to refer to the roles
played by participants in, and objects of, the HTTP communication.
connection ...
...
message
The basic unit of HTTP communication, consisting of a structured
sequence of octets matching the syntax defined in section 4 and
transmitted via the connection ...
...
request
An HTTP request message, as defined in section 5.
response
...
...
response
An HTTP response message, as defined in section 6.
resource
...
... active, a tunnel is not considered a party
to the HTTP communication, though the tunnel may have been
initiated by an HTTP request ...
... HTTP communication, though the tunnel may have been
initiated by an HTTP request. The tunnel ceases to exist when both
ends of the relayed connections ...
... the response message for use in answering subsequent requests. The
rules for determining the cachability of HTTP responses are
defined in section 13. Even if a resource is cachable, there may
be additional constraints ...
... metainformation, and possible entity-body content. The relationship
between HTTP and MIME is described in appendix 19.4.
...
... MIME is described in appendix 19.4.
Most HTTP communication is initiated by a user agent and consists of
a request to be applied to a resource on some origin server. In the
...
... travels the whole chain will pass through four separate connections.
This distinction is important because some HTTP communication options
may apply only to the connection with the nearest, non-tunnel ...
... requirements on cache behavior.
HTTP requirements for cache behavior and cachable responses are
...
... cache entries, organizations that distribute
subsets of cached data via CD-ROM, and so on. HTTP systems are used
in corporate intranets over high-bandwidth ...
... PDAs with low-power radio links and intermittent connectivity. The
goal of HTTP/1.1 is to support the wide diversity of configurations
already deployed while introducing protocol constructs that meet the
...
... TCP 80, but other ports can be used. This does not
preclude HTTP from being implemented on top of any other protocol on
the Internet, or on other networks ...
... the Internet, or on other networks. HTTP only presumes a reliable
transport; any protocol that provides such guarantees can be used;
...
... transport; any protocol that provides such guarantees can be used;
the mapping of the HTTP/1.1 request and response structures onto the
transport ...
... of this specification.
In HTTP/1.0, most implementations used a new connection for each
request/response ...
... connection for each
request/response exchange. In HTTP/1.1, a connection may be used for
one or more request/response ...
... US-ASCII double-quote mark (34)>
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
...
... LF
HTTP/1.1 headers can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear
...
... DIGIT
Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted
...
... SP | HT
Comments can be included in some HTTP header fields by surrounding
the comment text with parentheses. Comments are only allowed in
fields containing "comment" as part of their field value definition.
...
...
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
of the protocol. The protocol versioning policy is intended to allow
...
... the sender to indicate the format of a message and its capacity for
understanding further HTTP communication, rather than the features
obtained via that communication. No change is made to the version
number for the addition of message components which do not affect
...
...
The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message.
...
... The version of an HTTP message is indicated by an HTTP-Version field
in the first line of the message.
...
... Note that the major and minor numbers MUST be treated as separate
integers and that each may be incremented higher than a single digit.
Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
...
... Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
...
... version than HTTP/2.13, which in turn is
lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
MUST NOT be sent.
...
...
Applications sending Request or Response messages, as defined by this
specification, MUST include an HTTP-Version of "HTTP/1.1". Use of
this version number ...
... Applications sending Request or Response messages, as defined by this
specification, MUST include an HTTP-Version of "HTTP/1.1". Use of
this version number indicates that the sending application is at
...
... least conditionally compliant with this specification.
The HTTP version of an application is the highest HTTP version ...
... The HTTP version of an application is the highest HTTP version for
which the application is at least conditionally compliant.
...
...
Note: Converting between versions of HTTP may involve modification
of header fields required or forbidden by the versions ...
... URL) and Names (URN). As
far as HTTP is concerned, Uniform Resource Identifiers are simply
formatted strings which identify--via name, location, or any other
...
...
URIs in HTTP can be represented in absolute form or relative to some
known base URI, depending upon the context ...
... valid URLs as specified by RFC 1738(-> 4266prop | 4248prop), since HTTP servers
are not restricted in the set of unreserved characters allowed to
...
... unreserved characters allowed to
represent the rel_path part of addresses, and HTTP proxies may
receive requests for URIs ...
... 1738(-> 4266prop | 4248prop).
The HTTP protocol does not place any a priori limit on the length of
a URI. Servers MUST be able to handle the URI ...
...
The "http" scheme is used to locate network resources via the HTTP
protocol. This section defines the scheme-specific syntax and
semantics for http URLs ...
...
HTTP applications have historically allowed three different formats
for the representation of date/time stamps:
...
... 850(-> 1036) [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 ...
... clients and servers that parse the date value MUST accept
all three formats (for compatibility with HTTP/1.0), though they MUST
only generate the RFC 1123std3 format for representing HTTP ...
... HTTP/1.0), though they MUST
only generate the RFC 1123std3 format for representing HTTP-date values
in header fields.
...
...
Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been sent by non-HTTP
applications, as is sometimes the case when retrieving or posting
messages via proxies ...
... zone, and MUST be assumed when reading the asctime format.
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP ...
... | "Sep" | "Oct" | "Nov" | "Dec"
Note: HTTP requirements for the date/time stamp format apply only
...
...
Some HTTP header fields allow a time value to be specified as an
integer number of seconds, represented in decimal, after the time
...
... character set" is more commonly
referred to as a "character encoding." However, since HTTP and MIME
share the same registry ...
...
All content-coding values are case-insensitive. HTTP/1.1 uses
content-coding values in the Accept-Encoding (section 14.3) and
...
... not good design. For compatibility with previous implementations of
HTTP, applications should consider "x-gzip" and "x-compress" to be
equivalent to "gzip ...
...
All transfer-coding values are case-insensitive. HTTP/1.1 uses
transfer coding values in the Transfer-Encoding header field ...
... transport
has a different focus for an 8bit-clean transfer protocol. In HTTP,
the only unsafe characteristic of message-bodies is the difficulty in
determining the exact body length (section 7.2.2), or the desire to
...
... appropriate for the footer, such as Content-MD5 or future extensions
to HTTP for digital signatures or other facilities.
...
... appendix 19.4.6.
All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer coding, and MUST ignore transfer coding extensions
they do not understand. A server which receives an entity ...
... (Unimplemented), and close the connection. A server MUST NOT send
transfer-codings to an HTTP/1.0 client.
...
... the and inform the user of any problems discovered.
Note: some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications,
...
... Note: some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications,
implementations should only use media type parameters when they are
...
... canonical form. In
general, an entity-body transferred via HTTP messages MUST be
represented in the appropriate canonical form prior to its
...
... LF alone representing a line
break when it is done consistently for an entire entity-body. HTTP
applications MUST accept CRLF, bare CR ...
... LF as being
representative of a line break in text media received via HTTP. In
addition, if the text is represented in a character set that does not
...
... LF respectively, as is the case for
some multi-byte character sets, HTTP allows the use of whatever octet
sequences are defined by that character set to represent the
...
... or LF MUST NOT be substituted for CRLF within any of the HTTP control
structures (such as header fields and multipart boundaries).
...
... charset value of "ISO-8859-1" when
received via HTTP. Data in character sets other than "ISO-8859-1" or
...
... it is known that it will not confuse the recipient.
Unfortunately, some older HTTP/1.0 clients did not deal properly with
an explicit charset parameter ...
... clients did not deal properly with
an explicit charset parameter. HTTP/1.1 recipients MUST respect the
charset label provided by the sender ...
... line breaks between body-parts. Unlike in MIME, the
epilogue of any multipart message MUST be empty; HTTP applications
MUST NOT transmit the epilogue (even if the original multipart
contains an epilogue).
...
... contains an epilogue).
In HTTP, multipart body-parts MAY contain header fields which are
significant to the meaning of that part. A Content-Location ...
...
HTTP content negotiation (section 12) uses short "floating point"
numbers to indicate the relative importance ...
... range 0 through 1, where 0 is the minimum and 1 the maximum value.
HTTP/1.1 applications MUST NOT generate more than three digits after
the decimal point. User configuration of these values SHOULD also be
limited in this fashion.
...
... to other human beings. Computer languages are explicitly excluded.
HTTP uses language tags within the Accept-Language and Content-
...
...
The syntax and registry of HTTP language tags is the same as that
defined by RFC 1766(-> 3282draft | 3066(-> 4647 | 4646)) ...
... Entity tags are used for comparing two or more entities from the same
requested resource. HTTP/1.1 uses entity tags in the ETag (section
...
... range of) the
response entity be included within the response. HTTP/1.1 uses range
units in the Range ...
...
The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
implementations may ignore ranges ...
... The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
implementations may ignore ranges specified using other units.
...
... implementations may ignore ranges specified using other units.
HTTP/1.1 has been designed to allow implementations of applications
that do not depend on knowledge of ranges.
...
... HTTP Message ...
...
HTTP-message = Request | Response ; HTTP/1.1 messages
Request (section 5) and Response (section 6) messages use the generic
...
... 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 ...
... least one SP or HT. Applications SHOULD follow "common form" when
generating HTTP constructs, since there might exist some
implementations that fail to accept anything beyond the common forms.
...
...
The message-body (if any) of an HTTP message is used to carry the
entity-body associated with the request or response. The message-body ...
... For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
containing a message-body MUST include a valid ...
... valid Content-Length header
field unless the server is known to be HTTP/1.1 compliant. If a
request contains a message-body and a Content-Length ...
... Content-Length.
All HTTP/1.1 applications that receive entities MUST accept the
"chunked" transfer coding (section 3.6), thus allowing this mechanism
to be used for messages when the message length ...
... allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected.
...
... example would be
OPTIONS * HTTP/1.1
The absoluteURI form is required when the request is being made to a
...
... Request-Line would be:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
To allow for transition to absoluteURIs in all requests in future
...
... To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 ...
... versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients ...
... HTTP, all 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 ...
... Request-URI. For example, the request
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
would be forwarded by the proxy ...
... URL character for a reserved purpose. Implementers
should be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the Request-URI ...
...
HTTP/1.1 origin servers SHOULD be aware that the exact resource
identified by an Internet request is determined by examining both the
...
... section 19.5.1 for other requirements on Host support in HTTP/1.1.)
An origin server that does differentiate resources based on the host ...
... virtual hosts or vanity
hostnames) MUST use the following rules for determining the requested
resource on an HTTP/1.1 request:
1. If Request-URI ...
... receiving and interpreting a request message, a server responds
with an HTTP response message.
Response = Status-Line ; Section 6.1
...
... The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only recommended
-- they may be replaced by local equivalents without affecting the
...
... HTTP status codes are extensible. HTTP applications are not required
to understand the meaning of all registered status codes, though such
...
...
The entity-body (if any) sent with an HTTP request or response is in
a format and encoding defined by the entity ...
... TCP connection was
established to fetch each URL, increasing the load on HTTP servers
and causing congestion on the Internet ...
... and memory used for TCP protocol control blocks is also saved.
o HTTP requests and responses can be pipelined on a connection.
Pipelining ...
... state of the network.
o HTTP can evolve more gracefully; since errors can be reported
without the penalty of closing the TCP connection. Clients ...
... Clients using
future versions of HTTP might optimistically try a new feature, but
if communicating with an older server, retry with old semantics
...
... after an error is reported.
HTTP implementations SHOULD implement persistent connections.
...
... HTTP/1.1 and earlier versions of
HTTP is that persistent connections are the default behavior of any
HTTP ...
... HTTP is that persistent connections are the default behavior of any
HTTP connection. That is, unless otherwise indicated, the client may
...
...
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
maintain a persistent connection ...
... Clients and servers SHOULD NOT assume that a persistent connection is
maintained for HTTP versions less than 1.1 unless it is explicitly
signaled. See section 19.7.1 for more information on backwards
compatibility ...
... versions less than 1.1 unless it is explicitly
signaled. See section 19.7.1 for more information on backwards
compatibility with HTTP/1.0 clients.
...
... proxy, where N is the number of simultaneously active
users. These guidelines are intended to improve HTTP response times
and avoid congestion of the Internet ...
... connection.
o An HTTP/1.1 (or later) client MUST be prepared to accept a 100
(Continue) status followed by a regular response.
...
... (Continue) status followed by a regular response.
o An HTTP/1.1 (or later) server that receives a request from a
HTTP/1.0 (or earlier) client ...
... o An 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
...
... subject to these requirements from an
HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
...
... 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
input stream ...
... Clients SHOULD remember the version number of at least the most
recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or
...
... 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 close
...
... 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 or
...
... client has not seen an HTTP/1.1 or later response from
the server, it should assume that the server implements HTTP/1.0 or
older and will not use the 100 (Continue) response. If in this case
the client ...
... client SHOULD retry the request. If the client does
retry the request to this HTTP/1.0 server, it should use the
following "binary exponential backoff" algorithm to be assured of
...
...
The set of common methods for HTTP/1.1 is defined below. Although
this set can be expanded, additional methods cannot be assumed to
...
... The response to a GET request is cachable if and only if it meets the
requirements for HTTP caching described in section 13.
...
... return a message-body in the response. The metainformation contained
in the HTTP headers in response to a HEAD request SHOULD be identical
to the information sent in response to a GET request. This method ...
... URIs being defined by the origin server.
HTTP/1.1 does not define how a PUT method affects the state of an
...
... consisting only of the Status-Line and optional headers, and is
terminated by an empty line. Since HTTP/1.0 did not define any 1xx
status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 ...
... HTTP/1.0 did not define any 1xx
status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
client except under experimental ...
... The protocol should only be switched when it is advantageous to do
so. For example, switching to a newer version of HTTP is
advantageous over older versions, and switching to a real-time ...
... receiving
a 301 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.
...
... receiving
a 302 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.
...
... unacknowledged input buffers before they can be read and
interpreted by the HTTP application.
...
... entity MAY include
relevant diagnostic information. HTTP access authentication is
explained in section 11.
...
... 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.
...
... Authorization
header field (section 14.34). HTTP access authentication is explained
in section 11.
...
...
The server does not support, or refuses to support, the HTTP protocol
version that was used in the request message ...
... explaining the refusal.
The HTTP protocol does not restrict applications to this simple
challenge-response mechanism for access authentication ...
...
Most HTTP responses include an entity which contains information for
interpretation by a human user ...
... user agents are
equally capable of rendering all entity types. For that reason, HTTP
has provisions for several mechanisms for "content negotiation" --
...
... There are two kinds of content negotiation which are possible in
HTTP: server-driven and agent-driven negotiation. These two kinds of
...
... multiple user's requests.
HTTP/1.1 includes the following request-header fields for enabling
server-driven negotiation ...
... 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
...
... 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 ...
... HTTP/1.1.
HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
status codes for enabling agent ...
... 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 ...
... 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 ...
... 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 ...
... Caching in HTTP ...
...
HTTP is typically used for distributed information systems, where
performance can be improved by the use of response caches ...
... 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 ...
... 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,
headers ...
... 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
...
... operation require us to be able to relax the goal of semantic
transparency. The HTTP/1.1 protocol allows origin servers, caches,
and clients ...
... Warnings are always cachable, because they never weaken the
transparency of a response. This means that warnings can be passed to
HTTP/1.0 caches without danger; such caches will simply pass the
...
... practical or reasonable to display all of them to the user. This
version of HTTP does not specify strict priority rules for deciding
which warnings to display and in what order, but does suggest some
...
...
The basic cache mechanisms in HTTP/1.1 (server-specified expiration
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. We use the Cache-Control header ...
...
HTTP caching works best when caches can entirely avoid making
requests to the origin server. The primary mechanism for avoiding
...
... section 14.9.4 for a more restrictive way to force revalidation.
If an origin server wishes to force any HTTP/1.1 cache, no matter how
it is configured, to validate ...
...
Since origin servers do not always provide explicit expiration times,
HTTP caches typically assign heuristic expiration times, employing
...
... algorithms that use other header values (such as the Last-Modified
time) to estimate a plausible expiration time. The HTTP/1.1
specification does not provide specific algorithms, but does impose
...
... host performing the calculation." Hosts that use
HTTP, but especially hosts running origin servers and caches, should
...
... a globally accurate time standard.
Also note that HTTP/1.1 requires origin servers to send a Date header
with every response, giving the time at which the response was
...
... header, in a form appropriate for arithmetic operations.
HTTP/1.1 uses the Age response-header to help convey age information
between caches ...
... 2. age_value, if all of the caches along the response path
implement HTTP/1.1.
Given that we have two independent ways to compute the age of a
...
... and as long as we have either nearly synchronized clocks or all-
HTTP/1.1 paths, one gets a reliable (conservative) result.
Note that this correction is applied at each HTTP/1.1 ...
... HTTP/1.1 paths, one gets a reliable (conservative) result.
Note that this correction is applied at each HTTP/1.1 cache along the
path, so that if there is an HTTP/1.0 ...
... HTTP/1.1 cache along the
path, so that if there is an HTTP/1.0 cache in the path, the correct
received age is computed as long as the receiving ...
... ordering on responses, since it is possible that a later response
intentionally carries an earlier expiration time. However, the
HTTP/1.1 specification requires the transmission of Date headers on
every response, and the Date values are ordered to a granularity of
...
... overhead of an extra round trip if the cached
entry is invalid, the HTTP/1.1 protocol supports the use of
conditional methods.
...
... are defined in section 13.3.3.
In HTTP/1.1, a conditional request looks exactly the same as a normal
request for the same resource, except that it carries a special
header ...
... validation in
situations where it is inconvenient to store modification dates,
where the one-second resolution of HTTP date values is not
sufficient, or where the origin server wishes to avoid certain
paradoxes that may arise from the use of modification dates.
...
... entity.
The only function that the HTTP/1.1 protocol defines on validators is
comparison. There are two validator comparison ...
... to evaluate the condition.
These rules allow HTTP/1.1 caches and clients to safely perform sub-
...
... clients to safely perform sub-
range retrievals on values that have been obtained from HTTP/1.0
servers.
...
... lead to serious problems.
In other words, the preferred behavior for an HTTP/1.1 origin server
is to send both a strong entity tag ...
... cache-conditional
requests (using If-Modified-Since).
o If only a Last-Modified value has been provided by an HTTP/1.0
origin server, MAY use that value in subrange cache-conditional
...
... provided by the origin server, SHOULD use both validators in
cache-conditional requests. This allows both HTTP/1.0 and
HTTP/1.1 caches ...
... cache-conditional requests. This allows both HTTP/1.0 and
HTTP/1.1 caches to respond appropriately.
...
... caches to respond appropriately.
An HTTP/1.1 cache, upon receiving a request, MUST use the most
...
...
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
...
... clients should transmit as much non-
redundant information as is available in their responses and
requests. HTTP/1.1 systems receiving this information will make the
most conservative assumptions about the validators they receive.
...
... most conservative assumptions about the validators they receive.
HTTP/1.0 clients and caches will ignore entity ...
... tags. Generally,
last-modified values received or used by these systems will support
transparent and efficient caching, and so HTTP/1.1 origin servers
should provide Last-Modified values. In those rare cases where the
use of a Last-Modified value as a validator by an HTTP/1.0 ...
... HTTP/1.1 origin servers
should provide Last-Modified values. In those rare cases where the
use of a Last-Modified value as a validator by an HTTP/1.0 system
could result in a serious problem, then HTTP/1.1 origin servers
...
... use of a Last-Modified value as a validator by an HTTP/1.0 system
could result in a serious problem, then HTTP/1.1 origin servers
should not provide one.
...
... headers
(except Last-Modified, for compatibility with HTTP/1.0) are never
used for purposes of validating a cache entry.
...
... header to the current time.
Note that some HTTP/1.0 caches are known to violate this
expectation without providing any Warning.
...
...
The purpose of an HTTP cache is to store information received in
response to requests, for use in responding to future requests. In
...
... For the purpose of defining the behavior of caches and non-caching
proxies, we divide HTTP headers into two categories:
o End-to-end ...
... Hop-by-hop headers introduced in future versions of HTTP MUST be
listed in a Connection header ...
...
Some features of the HTTP/1.1 protocol, such as Digest
Authentication, depend on the value of certain end-to-end headers ...
... stronger authentication mechanisms are
introduced in later versions of HTTP. Such authentication
mechanisms may rely on the values of header fields not listed here.
...
... URLs as fresh unless
the server provides an explicit expiration time. This specifically
means that responses from HTTP/1.0 servers for such URIs should not
be taken from a cache ...
... reflect what the origin server would return for a new request.
There is no way for the HTTP protocol to guarantee that all such
cache entries are marked invalid. For example, the request that
...
...
The alternative (known as "write-back" or "copy-back" caching) is not
allowed in HTTP/1.1, due to the difficulty of providing consistent
updates and the problems arising from server, cache, or network ...
... viewing stale resources, this will tend to force service authors to
avoid using HTTP expiration controls and cache controls when they
would otherwise like to. Service ...
... This section defines the syntax and semantics of all standard
HTTP/1.1 header fields. For entity-header fields ...
... MUST transmit an Age header with a value of 2147483648 (2^31).
HTTP/1.1 caches MUST send an Age header in every response. Caches ...
... credentials
HTTP access authentication is described in section 11. If a request
is authenticated and a realm specified, the same credentials ...
... should be given in the response.
Note that HTTP/1.0 caches may not implement Cache-Control and may
...
... response. This mechanism supports extensibility; implementations of
future versions of the HTTP protocol may apply these directives to
header fields not defined in HTTP/1.1 ...
... HTTP protocol may apply these directives to
header fields not defined in HTTP/1.1.
The cache-control ...
... header is more restrictive. This rule allows an origin
server to provide, for a given response, a longer expiration time to
an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache ...
... an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be
useful if certain HTTP/1.0 ...
... HTTP/1.0 cache. This may be
useful if certain HTTP/1.0 caches improperly calculate ages or
expiration times, perhaps due to desynchronized clocks.
...
... wishing to use a Cache-Control directive that restricts, but does
not prevent, caching by an HTTP/1.1-compliant cache may exploit the
requirement ...
... requirement that the max-age directive overrides the Expires
header, and the fact that non-HTTP/1.1-compliant caches do not
observe the max-age directive.
...
... Cache-Control directive or, for
compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field
...
... The must-revalidate directive is necessary to support reliable
operation for certain protocol features. In all circumstances an
HTTP/1.1 cache MUST obey the must-revalidate directive; in
particular, if the cache ...
... or to reduce the amount of traffic on a slow link. HTTP has to date
been silent on these transformations.
...
... base protocol.
This extension mechanism depends on a HTTP cache obeying all of the
cache-control ...
... c