- From: Benjamin Franz <snowhare@netimages.com>
- Date: Sun, 18 Aug 1996 07:25:54 -0700 (PDT)
- To: "Roy T. Fielding" <fielding@liege.ICS.UCI.EDU>
- Cc: Jeffrey Mogul <mogul@pa.dec.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Sat, 17 Aug 1996, Roy T. Fielding wrote: > > I still don't believe that such count-forwarding is appropriate for a > proposed standard (experimental is okay), since I don't think that > people disable caching just to record hit-counts (which are already > known not to be an accurate measure of readers). Most people disable > caching by accident, and those that do it on purpose are normally > looking for Referer and IP/hostname (more than just a request count). As someone who has disabled caching on occasion - I couldn't care less about exact hit counts, referer or IP/hostname for the most part. I just want cache coherency - something many browsers are absolutely horrible at. Caching: o Never check x Check once per session o Check everytime is my enemy. It means shopping basket applications and other applications where what the user sees *MUST* match the state kept on the server blow up because of some browsers poor caching behavior. At least one browser will even cache GET _and_ POST results with pre-expired dates, No-Cache directives and *different* parameter data. My *ONLY* reliable option is cache busting via random URL components since it can insure that a browser *never* sees the same URL twice. It is NOT acceptable that '1%' of browsers _could_ show a user that items a,b,c, and e are in their basket when in reality items a,b,c and d are in it. There is legal liability involved for site operators if they ship the wrong things. IOW: I think this discussion of hit counts is off base. It addresses a problem that is minor (attempting to get *exact* hit counts - something that is _also_ made a hash of by people setting their browsers to 'non-standard compliant' caching to speed up their browse sessions - it simply doesn't matter if the *proxy* could report hits when the browser never makes the request in the second place) while the BIG problem of my being unable to insure that the user sees the *correct* information without cache busting URLs is still untouched. -- Benjamin Franz
Received on Sunday, 18 August 1996 07:28:40 UTC