W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

Re: http 1.1. Cache Response Codes...

From: David W. Morris <dwm@xpasc.com>
Date: Fri, 20 Mar 1998 10:26:13 -0800 (PST)
To: Michael Wexler <mwexler@nny.com>
Cc: http-wg@cuckoo.hpl.hp.com, Andy Norman <ange@hplb.hpl.hp.com>
Message-Id: <Pine.GSO.3.96.980320102349.15037B-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5483


Have you reviewed RFC 2227 -- "Simple Hit-Metering and Usage-Limiting for
HTTP"? Seems like this RFC is trying to solve your problem. 

Dave Morris

On Thu, 19 Mar 1998, Michael Wexler wrote:

> As a web measurement analyst, one of my worst problems is dealing with
> caching.  Why do we use the code 200 for everything?  Why not design the
> spec in a graduated fashion:
> 
> If browser has url in its local cache, it still sends a get request to the
> server, but an option says "I already have it, just letting you log the
> request". The success code is a 209, "user has non-expired data in cache".
> 
> If a non local cache has the data, same system.  The option can be
> different, and we can even use a different code (210), but for the most
> part, we should just let the 209 mean "cached request".
> 
> This solves many problems:
> 1) path analysis of a user's visit
> 2) advertising requests (not perfectly, given the IAB's recent standards,
> but better than nothing for smaller sites)
> 3) pages per visit calculations are accurate
> 4) this is a minor increase in bandwidth compared to not sending the
> request at all, and is far superior to eliminating caching.
Received on Friday, 20 March 1998 10:30:19 UTC

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