What is HTTP Delta Encoding? | 4
  
|
8. An example HTTP exchange
The proposed specification for HTTP delta encoding introduces a new concept called an "instance manipulation." A delta encoding format is one example of an instance manipulation. We discovered that we needed this new concept after trying to define delta encoding as a form of HTTP Content-encoding; that approach turned out to create insurmountable bugs, although it took us a long time to figure that out.
In our design, a client that supports delta encoding sends its request using the standard HTTP/1.1 "If-None-Match" header to list the entity tags of its cache entry (or entries) for the requested URL. (If you're not familiar with entity tags, please refer to the HTTP/1.1 specification [7].) It also sends an "A-IM" header listing the instance manipulation(s) that it can accept, including one or more delta encoding formats. So, for example, a request might look like
GET /foo.html HTTP/1.1 Host: bar.example.net If-None-Match: "123xyz" A-IM: vcdiff
Suppose that the entity tag for the current instance of this URL (https://bar.example.net/foo.html) is "489uhw". The origin server (which is never required to use a delta encoding!) could then locate its stored copy of the "123xyz" instance of the resource (which must be in the client's cache, or it would not have been listed in the If-None-Match header) and could compute the delta, using the vcdiff format.
If the result of this encoding is smaller than the current instance, the server would reply:
HTTP/1.1 226 IM Used
ETag: "489uhw"
IM: vcdiff
Date: Tue, 25 Nov 1997 18:30:05 GMT
<body containing delta encoding result, which
is a binary format>
The only differences between this response and a normal one are the new 226
status code, which tells the client that some instance manipulation has been
applied (and which precludes inappropriate caching by proxies that do not
understand this extension!), and the "IM" header, which tells the client which
instance manipulation has been applied. (Note that the 226 status code value
has not yet been formally allocated for this purpose.)
There are many other details to consider, which are discussed in the proposed specification.
Throughout most of this article, I have avoided referring to "browsers" or "proxies," since delta encoding can be used by any HTTP client with a cache. (The term "client" refers to anything that can receive an HTTP response, and so includes "proxies.")
There are situations where the difference between a proxy cache and the ultimate end-client can affect the use of delta encoding. For example, even if the end-client does not support delta encoding, if it sends its requests through a proxy, the proxy could request delta encoding and then decode the response before forwarding it to the client. (In fact, several research projects into delta encoding [1, 3] used proxy-based implementations to avoid having to modify browser code.)
Trace-based research suggests that a caching proxy server, if shared by multiple users, can obtain more benefit from delta encoding than if only the individual browsers used delta encoding. This is because the proxy, which sees many more requests, is more likely to have cached a previous response for a given URL. Since delta encoding (in its basic form) only works when the cache already contains an entry for the requested URL, a multi-user proxy cache is more likely to be able to request a delta.
10. Implementations and deployment status
If you are thinking about deploying an implementation based on the current proposed specification, don't. This would be a very bad idea.
The existing specification is definitely subject to change, and premature deployment could result in a standards mess.
However, it would be useful to have some experimental implementations of delta encoding, in order to verify that the proposed specification actually works. I know of no such implementations, except for one that conforms only to a much older, different version of the spec. Several research projects have produced code that does delta encoding, but they were not based on this specification.
Once the design progresses through "Proposed Standard" status to "Draft Standard" status, the design is less likely to change, and at that point we will be actively seeking the selective deployment of implementations for wide-scale testing. That won't happen very soon, though. The IETF process requires at least 6 months between a Proposed Standard and the subsequent Draft Standard.
We hope that people will start working on test-only implementations as soon as the Proposed Standard is available, because the IETF requires evidence of interoperability between independently-developed implementations before it will accept a Draft Standard.
Next Page: References
Comments are
welcome
Written by
Jeffrey C. Mogul and
Revised: November 14, 2000
URL: https://webreference.com/internet/software/servers/http/deltaencoding/intro/4.html
Find a programming school near you