W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1996

Some data related to the frequency of cache-busting

From: Shel Kaphan <sjk@amazon.com>
Date: Fri, 29 Nov 1996 11:27:58 -0800 (PST)
Message-Id: <199611291927.LAA04621@buglet.amazon.com>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1994


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.  These are typically dynamically generated and inserted
as components of hyperlinks in HTML documents, so that following these
links makes a uniquely identifiable request to the server.  This is
done not so much to make sure the response is not cached, but to make
sure that the response is not shared. (It is of course also done
sometimes to identify the client to the server -- much as cookies are
sometimes used).

This type of response is even less cache-friendly than "ordinary"
cache-busting, because the responses may well be cachable, and it is
pretty well guaranteed that nobody else will ever request the same

Not to beat a dead horse or anything, but the reason people use these
techniques is because they are the only way to guarantee some degree
of control over the user experience.  To really beat a _thoroughly_
dead horse, this is the case because caches and history mechanisms are
improperly conflated in most browsers.  The "correct" methods of
controlling cachability, with HTTP headers, are interpreted by
browsers in ways that screw up the user experience as well as
controlling the cache.  Until/unless this ever gets properly
addressed, people will have to use cache-unfriendly workarounds.

Received on Friday, 29 November 1996 11:32:40 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:00 UTC