- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Tue, 03 Dec 96 20:05:39 PST
- To: Shel Kaphan <sjk@amazon.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
There's another category of cache-busting that you did not mention in
the statistics you reported. This is the use of unique URL
components, which may be "once-only" URLs, or are at least unique for
a single user.
Right you are. I should have been more explicit in the title of
my message, and I didn't explain it clearly enough in the body
of the message, but this analysis was only aimed at finding instances
of cache-busting that might easily be avoided through use of our
hit-metering proposal. I thought it would be more realistic to
look for cache-busting that is done without using the unique-URL
technique.
It's not clear to me whether the users of once-only URLs would
switch to a more cache-friendly approach if our hit-metering
proposal were available. (Clearly, anyone that requires
cache-busting to provide usable results in the face of broken
history mechanisms is not going to switch, at least not until
virtually all browsers have fixed their history support.) So
I therefore assumed that non of the once-only URLs would be
amenable to hit-metering, and so I did not try to include these
URLs in my category of "possibly cache-busted responses."
On the other hand, it's not clear that I could have identified them
from their names. If they were pre-expired or had no last-modified
date, and they did not match my CGI filter, I would have included
them in my category of "possibly cache-busted responses" by mistake.
When I am ready to re-do the analysis, I'll try a version that is
limited to URLs for which the trace contains at least two status-200
responses. Presumably this will avoid any once-only URLs, right?
However, it will decrease the sample size by a large factor, which
means that the significance of the results may be weakened.
-Jeff
Received on Tuesday, 3 December 1996 20:26:29 UTC