- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 08 Mar 2000 15:08:03 -0800
- To: http-wg@hplb.hpl.hp.com
About a year ago, I gathered a long (90-day) proxy trace of HTTP requests, including MD5 digests of the response bodies. (No, you can't get access to this trace, so please don't even ask.) I've finished a pair of technical reports based on this trace: (1) "A trace-based analysis of duplicate suppression in HTTP" Compaq Western Research Lab Research Report 99/2, November 1999 Many HTTP resources (pages, graphics, etc.) are exact duplicates of other resources with different URLs. If an HTTP cache contains a duplicate of a requested resource, and could detect this, it could avoid substantial network costs by returning the cached duplicate in place of the requested URL. Previous studies have shown that there is substantial duplication of content in both HTTP and FTP, and several protocols have been proposed to support efficient and safe duplicate suppression in HTTP. We use traces covering millions of HTTP requests to quantify the potential benefit of an HTTP duplicate-suppression extension. In particular, we show that the benefits vary depending on content-type, and that a small fraction of Web servers account for most of the duplicated resources. http://www.research.digital.com/wrl/techreports/abstracts/99.2.html for Postscript & PDF format versions (2) "Errors in timestamp-based HTTP header values" Compaq Western Research Lab Research Report 99/3, December 1999 Many of the caching mechanism in HTTP, especially in HTTP/1.0, depend on header fields that carry absolute timestamp values. Errors in these values could lead to undetected cache incoherence, or to excessive cache misses. Using an extensive proxy trace, we looked for HTTP responses exhibiting several different categories of timestamp-related errors. A significant fraction of these responses have detectable errors in timestamp-based header fields. http://www.research.digital.com/wrl/techreports/abstracts/99.3.html for Postscript & PDF format versions -Jeff P.S.: The astute observer will notice that there is also a timestamp error in the date on one of these technical reports; I was a bit optimistic about when I would finish it, and then it was easier to issue it back-dated than to revise our report numbering scheme.
Received on Wednesday, 8 March 2000 15:10:42 UTC