W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: New document on "Simple hit-metering for HTTP"

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
Message-Id: <Pine.LNX.3.95.960818070016.580A-100000@ns.viet.net>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1398
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 

           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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC