HTTP
Click on the red underlined text to get to the source
... information to the user. Originally, the Hypertext Transfer Protocol
(HTTP) provided little support for caching, but under operational
pressures, it quickly evolved to support a simple mechanism for
maintaining cache ...
... cache entry is still
valid. HTTP/1.0 also includes a means for the server to indicate,
via an "Expires" timestamp, that a response will be valid ...
... 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 ...
... In spite of this history, it appears to have taken several years
before anyone thought of applying delta encoding to HTTP, perhaps
because the development of HTTP caching has been somewhat haphazard.
...
... encoding to HTTP, perhaps
because the development of HTTP caching has been somewhat haphazard.
The first published suggestion for delta encoding appears to have
...
... The first published suggestion for delta encoding appears to have
been by Williams et al. in a paper about HTTP cache removal policies
[30 ...
... 15] appears to be the first published
description of an implementation of delta encoding for HTTP (which
they call "differencing"). WebExpress is aimed specifically at
wireless ...
... wireless environments, and includes a number of orthogonal
optimizations. Also, the WebExpress design does not propose changing
the HTTP protocol itself, but rather uses a pair of interposed
proxies to convert the HTTP message ...
... HTTP protocol itself, but rather uses a pair of interposed
proxies to convert the HTTP message stream into an optimized form.
The results reported for WebExpress differencing are impressive, but
...
... latency by anticipating a "Not Modified" response
from the origin server. The optimistic delta paper, like the
WebExpress paper, did not propose a change to the HTTP protocol
itself, and reported results only for a small set of selected URLs.
...
... 23] collected lengthy traces, at two different sites,
of the full contents of HTTP messages, to quantify the potential
benefits of delta-encoded responses. They showed that delta encoding
...
... encoding
can provide remarkable improvements in response-size and response-
delay for an important subset of HTTP content types. They proposed a
set of HTTP ...
... HTTP content types. They proposed a
set of HTTP extensions, but without the level of detail required for
a specification. Douglis et al. [8] used the same sets of full-
...
... by Marimba, Netscape, Sun, Novell, and At Home, aims to provide a
collection of new features for HTTP, to support "the efficient
replication of data over HTTP ...
... HTTP, to support "the efficient
replication of data over HTTP" [13]. One aspect of the DRP proposal
is the use of "differential downloading," which is essentially a form
...
... The goals of this proposal are:
1. Reduce the mean size of HTTP responses, thereby improving
latency and network ...
... The goals do not include:
- Reducing the number of HTTP requests sent to an origin server.
- Reducing the size of every HTTP message ...
... HTTP requests sent to an origin server.
- Reducing the size of every HTTP message.
- Increasing the cache ...
... [21]. Unfortunately, the definition for "entity" in HTTP/1.1 is
similar to that used in MIME [12 ...
... entity."
In HTTP, however, a response message to a GET does not have a
distinct and separate existence. Rather, it reflects the current
state ...
... 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
...
...
We will informally use the term "delta," in this document, to mean an
HTTP response encoded as the difference between two instances.
More formally, delta encodings ...
... The HTTP message-generation sequence ...
...
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
...
... One must understand the relationship between these transformations in
order to see how delta encoding applies to HTTP responses.
Conceptually, the various transformations are applied in the
...
... message-body
This formalization of the HTTP message generation sequence has not
previously been described. However, it is clear that Range selection
...
... 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 ...
... hop-by-hop
transformation and is not the most efficient approach (especially if
an HTTP/1.0 proxy is in the path).
...
... 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 ...
... "conditional GET", using one of two forms of "cache validators." In
the traditional form, available in both HTTP/1.0 and in HTTP/1.1, the
client ...
... 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 ...
... along with a complete copy of the resource.
In the existing HTTP protocol (HTTP/1.0 or HTTP/1.1), a client ...
... 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-
...
... client indicates it is willing to accept deltas,
but the server does not support this form of instance-manipulation,
the server will simply ignore this aspect of the request. (HTTP
always allows an implementation to ignore a header that is not
...
... mechanism. Because the Internet still includes a significant number
of HTTP/1.0 caches, which might never be entirely replaced, and
because the HTTP ...
... HTTP/1.0 caches, which might never be entirely replaced, and
because the HTTP specifications insist that message recipients ignore
any header field that they do not understand, a non-delta-capable
...
... To solve this problem, we propose that delta-encoded responses
(actually, all instance-manipulated responses) be identified as such
using a new HTTP status code. For specificity in the discussion that
follows, we will use the (currently unassigned) code of 226, with a
...
... 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 ...
... status code would be to use the
"Expires" header to prevent HTTP/1.0 caches from storing the
response, then use "Cache-Control ...
... 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
...
... effectiveness of delta encoding. It is also not entirely clear that
this approach suppresses all caching by all HTTP/1.0 proxies.
...
... encoding. However, we see no other
efficient way to remain compatible with the deployed base of
HTTP/1.0 cache implementations.
...
... 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
...
... headers, we suggest that, after some period of
experimentation, it might be reasonable to specify a "recommended"
set of delta formats for general-purpose HTTP implementations.
We suspect that it should be possible to devise a delta encoding ...
... 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 ...
... encoding format used in the response.) Of course,
such uses are subject to all of the other HTTP rules concerning
the validity of cache ...
... 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
...
...
When a recipient reassembles a complete HTTP response from several
individual messages, it might be necessary to check the integrity of
...
... 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 ...
...
This specification defines a new HTTP parameter type, an instance-
manipulation:
...
...
This specification also inserts a new value in the IANA HTTP Status
Code Registry (see RFC 2817 [18 ...
...
The following new status code is defined for HTTP.
...
... 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].
...
... cache and used in reply to a subsequent request, subject to the HTTP
expiration mechanism and any Cache-Control headers ...
... 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
...
... cache. In
this case, the recovered instance is stored as a status-200
response, and MUST be used in accordance with the normal HTTP
caching rules.
...
... cache. In this
case, the result is stored as a status-206 response, and MUST
be used in accordance with the normal HTTP caching rules for
Partial Content.
...
... A server that does support diffe might reply:
HTTP/1.1 226 IM Used
Date: Wed, 24 Dec 1997 14:01:00 GMT ...
...
The proposed protocol changes increase the size of the HTTP message
headers slightly. In the simplest case, a conditional request (i.e.,
...
... encoding mechanism
that affect the existing security considerations for the HTTP/1.1
protocol.
...
... Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. ...
... 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. ...
... Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Luotonen, L. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authnetication", RFC 2617draft, June 1999. ...
... Arthur van Hoff, John Giannandrea, Mark Hapner, Steve Carter, and Milo Medin. The HTTP Distribution and Replication Protocol. Technical Report NOTE-DRP, World Wide Web Consortium, August, 1997. ...
... Jeffrey C. Mogul, Fred Douglis, Anja Feldmann, and Balachander Krishnamurthy. Potential benefits of delta encoding and data compression for HTTP. Research Report 97/4, DECWRL, July, 1997. ...