Re: Some data related to the frequency of cache-busting

Larry Masinter writes:
 > Shel,
 > 
 > Are you saying that none of the current proposals for hit metering
 > will help with unique-URL cache-busting because they don't actually
 > address the problem of browser behavior?
 > 

I am not entirely up to speed on the proposals, so I can't really
comment on them, but I don't have to be that familiar with them to
make the point, because what I _am_ saying is that cache-busting will
continue to be practiced for reasons other than hit-metering, using
techniques even more evil (from the cache abuse perspective) than
pre-expiring documents.

It's friendlier to caches to tell them _not_ to cache documents that
are requested using unique URLs, since you know they'll never be
requested again, but since pre-expiration is one of those things that
makes browsers behave weirdly (within the spec, I might add), it is
avoided for that reason.


 > # 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.
 > 
 > Don't cookies do the right thing?
 > 

In their domain they do the right thing (unless they get cached in a
1.0 cache that doesn't know about cookies!)  But they are not
universally supported (yet), and they don't really address any of the
document expiration-related problems that browsers have.  Also, as
long as there is any doubt about the correctness of caches, and right
now there is plenty of doubt, unique URLs are _much_ more reliable
than any other means to make sure that the client gets the requested
document and not some out of date version, or one intended for someone
else.  Of course, 1.1 and future versions will improve this whole story,
eventually, but if there are protocol features that remain too tricky
to use because of things browsers do, the situation isn't going to
improve much.  Service providers care more about correctness than
cache and bandwidth friendliness.

 > # To really beat a _thoroughly_ dead horse, this is the case because
 > # caches and history mechanisms are improperly conflated in most
 > # browsers.
 > 
 > Didn't we 'fix' this with HTTP/1.1?
 > 
 > Larry
 > 
 > 

If the browser guys read the spec carefully enough, and follow the
recommendations as well as the requirements, the situation will be
_improved_ (eventually), but to really get this one nailed, I don't
really believe that the small amount of verbiage we threw at it is going
to be enough. To get it "right", we'd need to allow for the kind of
browser controls in HTTP that nobody wants to contemplate because it
seems to many people to be a mixing of levels that makes people
uncomfortable.  I can understand that concern and even sympathize with
it, but that doesn't make the issues go away.

If you read the spec, already understanding the issue, you'll see that
the issue is addressed, but if, as an implementer, you don't already
grok the architectural significance, you are unlikely to be
sufficiently guided by what is in the spec.  (There's only so much
network specs can do).

To my mind the problem is that there seems to be no forum in which it
is appropriate and effective to discuss the interaction of HTTP and
the subtleties of browser behavior.  In this working group we just
want to stick to the "bits on the wire", which is certainly
understandable.  But I think with HTTP we have a new kind of beast,
and the problems that I'd like to be able to work on can't be solved
by thinking only about bits on the wire.

That said, I'm kind of resigned to the fact that this isn't going to
be dealt with any time soon at the protocol level, and that, as a
practical matter, one does what one has to do, which is of course very
sad for the scalability of the internet, improved bandwidth usage, and
flexibility of new kinds of web-based services.  People will find
answers but they may not be very pretty ones.

--Shel

Received on Friday, 29 November 1996 18:09:54 UTC