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: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Sun, 18 Aug 1996 23:22:32 -0700
To: Benjamin Franz <snowhare@netimages.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9608182322.aa13328@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1399
> 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. 

The "must-revalidate" cache-response-directive was created to fix that
problem and we have yet to see whether or not it will be sufficient.
The protocol is not capable of fixing the problem any better than that,
since the actual cause of your woes is simply that using state-marked URLs
or cookies for storing and exchanging market-basket state is a poor
design for a distributed client/server system.  If you want to do better,
you will need to convince the browser makers to define a standard for
identifying purchasable items in HTML and a client-side "basket window"
for manipulating items to be purchased via a POST request to one or more
"cashier" resources (also identified in the HTML) which can verify the
entire purchase (including cost/item and availability) before authorizing
the sale.  No changes to HTTP are necessary, and it is completely resistant 
to caching; in fact, it is cache-friendly.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
Received on Sunday, 18 August 1996 23:32:46 UTC

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