HTTP/1.1
Click on the red underlined text to get to the source
... that time, without first validating it using a conditional retrieval.
HTTP/1.1 [10] adds many new features to improve cache coherency and
...
... avoid transferring pieces that have not changed.
This document proposes a set of compatible extensions to HTTP/1.1
that allow clients and servers to use delta encoding ...
... [21]. Unfortunately, the definition for "entity" in HTTP/1.1 is
similar to that used in MIME [12 ...
... subject to a set of constraints).
The HTTP/1.1 specification has no term to describe "the value that
would be returned in response to a GET request at the current time
for the selected variant of the specified resource." This leads to
...
... would be returned in response to a GET request at the current time
for the selected variant of the specified resource." This leads to
awkward wordings in the HTTP/1.1 specification in places where this
concept is necessary.
...
... It is convenient to think of an entity tag, in HTTP/1.1, as being
associated with an instance, rather than an entity. That is, for a
...
...
HTTP/1.1 supports a number of different transformations on the body
of a value:
...
... that the server return one or more subranges of the
instance, rather than the entire instance value.
HTTP/1.1 only supports byte-ranges, although there is
some possibility that future extensions will allow
...
... have to be applied after the compression. This is feasible in
unmodified HTTP/1.1, because the compression can be done as a
content-coding. However, if the client ...
... cache, and wishes to ensure that
this cache entry is current, HTTP/1.1 allows the client to do a
"conditional GET", using one of two forms of "cache ...
... cache validators." In
the traditional form, available in both HTTP/1.0 and in HTTP/1.1, the
client may use the "If-Modified-Since" request-header ...
... of timestamp resolution: if a resource changes twice during one
second, the change might not be detectable. Therefore, HTTP/1.1 also
allows the server to provide an entity tag ...
... In the existing HTTP protocol (HTTP/1.0 or HTTP/1.1), a client
sending a conditional request can expect either of two responses:
...
...
In order to support the transmission of actual deltas, an extension
to HTTP/1.1 needs to provide these features:
1. A way to mark a request as conditional.
...
... format.
The first two features are already provided by HTTP/1.1: the presence
of a conditional request-header (such as "If-Modified-Since" or "If-
...
... normally be seen by human users.) There is some precedent for this
approach: the HTTP/1.1 specification introduces the 206 (Partial
Content) status code, for the transmission of sub-ranges ...
... caches from storing the
response, then use "Cache-Control: max-age" (defined in HTTP/1.1) to
allow more modern caches to store delta-encoded responses. This adds
...
... cache a response with an unknown 2xx status code,
the HTTP/1.1 specification does allow this behavior if the response
carries an Expires or Cache-Control header field ...
... The solution in that case is to exploit the Cache Control Extensions
mechanism from the HTTP/1.1 specification. We define a new cache-
directive, "im", which indicates that the "no-store" cache ...
...
"MUST NOT" be stored by a cache that complies with the HTTP/1.1
specification (which states that the max-age cache-directive "implies
...
... caching.
We are not entirely sure that all HTTP/1.1 caches obey the rule
that the max-age directive is overridden by the no-store
...
... cache). The server
should return a 304 (Not Modified) response, as
required by the HTTP/1.1 specification for "If-None-
Match".
...
...
Tcur = "B" (i.e., the instance has not changed again). The
HTTP/1.1 specification for "If-None-Match", in this
case, is that the header field is ignored (by a
...
...
Tcur = "C" (i.e., the instance has changed again). In this
case, the HTTP/1.1 specification for "If-None-Match"
again means that this is equivalent to an
unconditional ...
... entire current instance, so it could send this request:
GET /foo.html HTTP/1.1
host: bar.example.net
...
... tag
in an "If-None-Match" header, the HTTP/1.1 specification allows the
header to carry more than one entity ...
... entity-tag. This feature was included
in HTTP/1.1 to support efficient caching of multiple variants of a
resource, but it is not restricted to that use.
...
... unconditional request, the server might send:
HTTP/1.1 200 OK
ETag: "337pey"
Date: Tue, 25 Nov 1997 18:30:05 GMT ...
... particular time. For example,
HTTP/1.1 200 OK
ETag: "337pey"
Date: Tue, 25 Nov 1997 18:30:05 GMT ...
... client, and the proxy has a complete copy of an up-to-
date ("fresh," in HTTP/1.1 terminology) response in its cache,
it could generate a delta locally and return it to the
...
... client or
server) might have a bug.
HTTP/1.1 includes mechanisms for ensuring the integrity of individual
messages. A message may include a "Content-MD5 ...
... headers from the
status-226 response and the other instances, following the rules in
section 13.5.3 of the HTTP/1.1 specification [10].
...
... A-IM field, then
it is acceptable, unless it is accompanied by a qvalue of 0.
(As defined in section 3.9 of the HTTP/1.1 specification [10],
a qvalue of 0 means "not acceptable.") A server MUST NOT use a
...
... A server that does support diffe might reply:
HTTP/1.1 226 IM Used
Date: Wed, 24 Dec 1997 14:01:00 GMT ...
... encoding mechanism
that affect the existing security considerations for the HTTP/1.1
protocol.
...
... Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. Berners- Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068(-> 2616draft), January 1997. ...
... Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616draft, June 1999. ...