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, or 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
...
...
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.
...
... 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.
...
... 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 ...
... An HTTP request message, as defined in section 5. ...
... An HTTP response message, as defined in section 6. ...
... filtering. Except
where either transparent or non-transparent behavior is explicitly
stated, the HTTP proxy requirements apply to both types of
...
... 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 cacheability of HTTP responses are
defined in section 13. Even if a resource is cacheable, there may
be additional constraints ...
... metainformation, and possible entity-body content. The relationship
between HTTP and 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 cacheable 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
...
... 19], 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 ...
... on 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 ...
... connection for each
request/response exchange. In HTTP/1.1, a connection may be used for
one or more request/response ...
...
HTTP/1.1 header field values can be folded onto multiple lines if the
continuation line begins with a space or horizontal tab. All linear
...
...
Many HTTP/1.1 header field values consist of words separated by LWS
or special characters. These special characters MUST be in a quoted
...
...
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.
...
... An application that sends a request or response message that includes
HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
with this specification. Applications that are at least conditionally
...
... response message that includes
HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
with this specification. Applications that are at least conditionally
compliant with this specification SHOULD use an HTTP-Version ...
... HTTP/1.1" MUST be at least conditionally compliant
with this specification. Applications that are at least conditionally
compliant with this specification SHOULD use an HTTP-Version of
"HTTP/1.1" in their messages, and MUST do so for any message that is
...
... compliant with this specification SHOULD use an HTTP-Version of
"HTTP/1.1" in their messages, and MUST do so for any message that is
not compatible with HTTP/1.0. For more details on when to send
...
... "HTTP/1.1" in their messages, and MUST do so for any message that is
not compatible with HTTP/1.0. For more details on when to send
specific HTTP-Version values, see RFC 2145 ...
... not compatible with HTTP/1.0. For more details on when to send
specific HTTP-Version values, see RFC 2145 [36].
...
... The HTTP version of an application is the highest HTTP version for
which the application is at least conditionally compliant.
...
...
Due to interoperability problems with HTTP/1.0 proxies discovered
since the publication of RFC 2068(-> 2616draft) ...
...
Note: Converting between versions of HTTP may involve modification
of header fields required or forbidden by the versions ...
... URN)
[20]. As far as HTTP is concerned, Uniform Resource Identifiers are
simply formatted strings which identify--via name, location, or any
...
...
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. See section 19.3 for further information.
...
...
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 ...
... Greenwich Mean Time
(GMT), without exception. For the purposes of HTTP, GMT is exactly
equal to UTC ...
... GMT" as the three-letter
abbreviation for time zone, and MUST be assumed when reading the
asctime format. HTTP-date is case sensitive and MUST NOT include
additional LWS beyond that specifically included as SP in the
...
...
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 ...
...
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 ...
...
All content-coding values are case-insensitive. HTTP/1.1 uses
content-coding values in the Accept-Encoding (section 14.3) and
...
... use here is representative of historical practice, not good
design. For compatibility with previous implementations of HTTP,
applications SHOULD consider "x-gzip" and "x-compress" to be
...
...
All transfer-coding values are case-insensitive. HTTP/1.1 uses
transfer-coding values in the TE 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
...
... not understand SHOULD return 501 (Unimplemented), and close the
connection. A server MUST NOT send transfer-codings to an HTTP/1.0
client.
...
...
The trailer allows the sender to include additional HTTP header
fields at the end of the message. The Trailer header field can be
used to indicate which header fields ...
... requirement prevents an interoperability failure when the
message is being received by an HTTP/1.1 (or later) proxy and
forwarded to an HTTP/1.0 ...
... HTTP/1.1 (or later) proxy and
forwarded to an HTTP/1.0 recipient. It avoids a situation where
compliance with the protocol would have necessitated a possibly
infinite buffer ...
...
All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer-coding, and MUST ignore chunk-extension extensions
they do not understand.
...
...
Note that some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications,
...
... Note that 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. An
entity-body transferred via HTTP messages MUST be represented in the
appropriate canonical form prior to its transmission except for
...
... 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
...
... Unlike in RFC 2046draft, the epilogue of any multipart message MUST be
empty; HTTP applications MUST NOT transmit the epilogue (even if the
original multipart contains an epilogue). These restrictions exist in
order to preserve the self-delimiting nature of a multipart message-
...
... payload. The one exception is the
"multipart/byteranges" type (appendix 19.2) when it appears in a 206
(Partial Content) response, which will be interpreted by some HTTP
caching mechanisms as described in sections 13.5.4 and 14.16. In all
other cases, an HTTP ...
... HTTP
caching mechanisms as described in sections 13.5.4 and 14.16. In all
other cases, an HTTP user agent SHOULD follow the same or similar
behavior as a MIME ...
... The MIME header fields within each body-part of a multipart message-
body do not have any significance to HTTP beyond that defined by
their MIME semantics ...
...
HTTP content negotiation (section 12) uses short "floating point"
numbers to indicate the relative importance ...
... value. If a parameter has a quality value of 0, then content with
this parameter is `not acceptable' for the client. HTTP/1.1
applications MUST NOT generate more than three digits after the
decimal point. User configuration of these values SHOULD also be
...
... 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.
...
...
HTTP/1.1 has been designed to allow implementations of applications
that do not depend on knowledge of ranges.
...
... HTTP Message ...
... 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 ought to follow "common form", where
one is known or indicated, 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 ...
...
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.
...
... HTTP-Version ...
...
OPTIONS * HTTP/1.1
...
...
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
...
... 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 ...
... URI character for a reserved purpose. Implementors
should be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the Request-URI ...
... Host header field value when
determining the resource identified by an HTTP/1.1 request. (But see
section 19.6.1.1 for other requirements on Host ...
... virtual hosts or vanity host
names) MUST use the following rules for determining the requested
resource on an HTTP/1.1 request:
...
... receiving and interpreting a request message, a server responds
with an HTTP response message.
...
... HTTP-Version ...
... 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
recommendations -- they MAY be replaced by local equivalents without
...
... | "504" ; Section 10.5.5: Gateway Time-out
| "505" ; Section 10.5.6: HTTP Version not supported
| extension-code
...
... 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 ...
... 26] [30]. Implementation experience and
measurements of actual HTTP/1.1 (RFC 2068(-> 2616draft)) implementations show good
results [39 ...
...
Persistent HTTP connections have a number of advantages:
...
... 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 ...
...
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
...
...
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.6.2 for more information on backward
compatibility ...
... versions less than 1.1 unless it is explicitly
signaled. See section 19.6.2 for more information on backward
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.
...
...
Requirements for HTTP/1.1 origin servers:
...
... request-header
field with the "100-continue" expectation, and MUST NOT send a
100 (Continue) response if such a request comes from an HTTP/1.0
(or earlier) client. There is an exception to this rule: for
...
... compatibility with RFC 2068(-> 2616draft), a server MAY send a 100 (Continue)
status in response to an HTTP/1.1 PUT or POST request that does
not include an Expect request-header field with the "100-
...
... client processing delays associated with an
undeclared wait for 100 (Continue) status, applies only to
HTTP/1.1 requests, and not to requests with any other HTTP-
version ...
... undeclared wait for 100 (Continue) status, applies only to
HTTP/1.1 requests, and not to requests with any other HTTP-
version value. ...
... proxy
either knows that the next-hop server complies with HTTP/1.1 or
higher, or does not know the HTTP version ...
... next-hop server complies with HTTP/1.1 or
higher, or does not know the HTTP version of the next-hop
...
... version of the next-hop server is
HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
respond with a 417 (Expectation Failed) status. ...
... Proxies SHOULD maintain a cache recording the HTTP version
numbers received from recently-referenced next-hop servers. ...
... proxy MUST NOT forward a 100 (Continue) response if the
request message was received from an HTTP/1.0 (or earlier)
client and did not include an Expect request-header ...
...
If an HTTP/1.1 client sends a request which includes a request body,
but which does not include an Expect request-header ...
... "100-continue" expectation, and if the client is not directly
connected to an HTTP/1.1 origin server, and if the client sees the
connection ...
...
The set of common methods for HTTP/1.1 is defined below. Although
this set can be expanded, additional methods cannot be assumed to
...
... Content-Type field. Although this
specification does not define any use for such a body, future
extensions to HTTP might use the OPTIONS body to make more detailed
queries on the server. A server that does not support such an
...
... the capabilities of the server. For example, this can be used to test
a proxy for HTTP/1.1 compliance (or lack thereof).
...
...
body is not defined by this specification, but might be defined by
future extensions to HTTP. Content negotiation MAY be used to select
the appropriate response format ...
... The response to a GET request is cacheable 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 ...
... class of status code. Since HTTP/1.0 did not define any 1xx status
codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client ...
... status code. Since 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 be switched only 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.
...
... response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s) , since many pre-HTTP/1.1 user agents do not
understand the 307 status. Therefore, the note SHOULD contain the
...
... client's unacknowledged input buffers
before they can be read and interpreted by the HTTP application.
...
... entity might
include relevant diagnostic information. HTTP access authentication
is explained in "HTTP Authentication: Basic and Digest Access
Authentication ...
... diagnostic information. HTTP access authentication
is explained in "HTTP Authentication: Basic and Digest Access
Authentication" [43].
...
...
Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the
...
... Authorization
header field (section 14.34). HTTP access authentication is explained
in "HTTP Authentication: Basic and Digest Access Authentication ...
... header field (section 14.34). HTTP access authentication is explained
in "HTTP Authentication: Basic and Digest Access Authentication"
[43 ...
... upstream server specified by the URI (e.g.
HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS ...
... The server does not support, or refuses to support, the HTTP protocol
version that was used in the request message ...
...
HTTP provides several OPTIONAL challenge-response authentication
mechanisms which can be used by a server to challenge a client
request ...
... access authentication, and the specification of
"basic" and "digest" authentication, are specified in "HTTP
Authentication: Basic and Digest Access Authentication" [43]. This
...
...
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
...
...
HTTP/1.1 includes the following request-header fields for enabling
server-driven negotiation ...
... 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 ...
... negotiation, though it also does not prevent any such mechanism from
being developed as an extension that could be used within HTTP/1.1.
...
... 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 ...
... cache all Warnings in responses, without
deleting the ones in the first category. Warnings in responses that
are passed to HTTP/1.0 caches carry an extra warning-date field,
which prevents a future HTTP/1.1 ...
... HTTP/1.0 caches carry an extra warning-date field,
which prevents a future HTTP/1.1 recipient from believing an
erroneously cached Warning.
...
... 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 might 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
...
...
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
...
...
HTTP/1.1 requires origin servers to send a Date header, if possible,
with every response, giving the time at which the response was
...
...
and as long as we have either nearly synchronized clocks or all-
HTTP/1.1 paths, one gets a reliable (conservative) result.
...
... response is first-hand unless all caches along the request path are
compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
...
... caches along the request path are
compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
the Age header field ...
... overhead of an extra round trip if the cached
entry is invalid, the HTTP/1.1 protocol supports the use of
conditional methods.
...
...
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 might arise from the use of modification dates.
...
...
The only function that the HTTP/1.1 protocol defines on validators is
comparison. There are two validator comparison ...
... clients to safely perform sub-
range retrievals on values that have been obtained from HTTP/1.0
servers.
...
...
HTTP/1.1 origin servers:
...
...
In other words, the preferred behavior for an HTTP/1.1 origin server
is to send both a strong entity tag ...
... 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. ...
...
An HTTP/1.1 origin server, upon receiving a conditional request that
includes both a Last-Modified date (e.g., in an If-Modified-Since or
...
...
Note: The general principle behind these rules is that HTTP/1.1
servers and clients should transmit as much non-redundant
...
... 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.
...
... 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
...
... 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 should not provide one.
...
... 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 should not provide one.
...
... headers
(except Last-Modified, for compatibility with HTTP/1.0) are never
used for purposes of validating a cache entry.
...
...
Note: 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:
...
...
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 ...
... URIs 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 ...
...
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 ...
... identity" content-coding is unavailable, then
content-codings commonly understood by HTTP/1.0 clients (i.e.,
"gzip ...
...
Note: Most HTTP/1.0 applications do not recognize or obey qvalues
associated with content-codings. This means that qvalues will not
work and are not permitted with x-gzip ...
... overflows, it MUST transmit an Age header with a value of
2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST
include an Age header field ...
...
HTTP access authentication is described in "HTTP Authentication:
Basic and Digest Access Authentication ...
...
HTTP access authentication is described in "HTTP Authentication:
Basic and Digest Access Authentication" [43 ...
... response. This mechanism supports extensibility; implementations of
future versions of the HTTP protocol might apply these directives to
header fields not defined in HTTP/1.1 ...
... 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 might be
useful if certain HTTP/1.0 ...