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: Erik Aronesty <earonesty@montgomery.com>
Date: Fri, 9 Aug 1996 17:31:41 -0700
Message-Id: <c=US%a=_%p=Montgomery%l=EXCHANGE_SERVE-960810003141Z-664@sf-exch-2.montgomery.com>
To: "'koen@win.tue.nl'" <koen@win.tue.nl>, 'Jeffrey Mogul' <mogul@pa.dec.com>
Cc: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
this is just selective cache-busting....the proxy has know way of
knowing if
the document "actually varies" so the entire document gets sent for each
variation.

perhaps the server should send

Cache-Control-Vary

or some such nonsense

BTW:

it would be nice to be able to vary by *.com, *.edu, *.org ... and still
have everything work.





>----------
>From: 	Jeffrey Mogul[SMTP:mogul@pa.dec.com]
>Sent: 	Friday, August 09, 1996 6:45 PM
>To: 	koen@win.tue.nl
>Cc: 	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com; mogul@pa.dec.com
>Subject: 	Re: New document on "Simple hit-metering for HTTP" 
>
>    This is very interesting...  I wrote earlier that we need to
>    distinguish between two kinds of demographic data:
>    
>    1) Hit counts
>    
>    2) User's Referer field, IP address, User-Agent field, ...
>    
>    The proposed hit counting mechanism allows you to get 1) for all
>user
>    agents without cache busting, but not 2).  You seem to predict that
>    most advertising sites will want to have 2) in future.  That would
>    make the the proposed hit counting mechanism pretty ineffective at
>    reducing cache busting.
>
>This is not true.  For any field that appears in the client's
>request headers (i.e., not "IP address" but definitely User-Agent),
>you can obtain counts without cache-busting (which I would
>define as "completely disabling caching").
>
>E.g., suppose I (at an origin server) want to subdivide the count
>based on User-Agent.  I would send "Vary: User-Agent" with my
>responses, but I would still send the same Etag header with each
>response.
>
>So the first time the cache does a GET on the URL, e.g.,
>
>	GET /foo.html HTTP/1.1
>	User-Agent: Lynx
>	Cache-control: use-count=0
>
>I would reply
>
>	HTTP/1.1 200 OK
>	Etag: "abc"
>	Vary: User-Agent
>	Content-Length: 10000
>	Cache-control: max-uses=1000
>	[...]
>
>Then when the cache receives another request from a Mosaic user, it
>would send
>
>	GET /foo.html HTTP/1.1
>	User-Agent: Mosaic
>	Cache-control: use-count=0
>	If-None-Match: "abc"
>
>and I would reply
>
>	HTTP/1.1 304 Not Modified
>	Etag: "abc"
>	Cache-control: max-uses=1000
>
>I.e., the cache now knows that it can use the entity with Etag = "abc"
>for both Mosaic and Lynx User-agents, and that I want it to keep
>separate counts based on User-agent.  Only one copy of the body
>has been transmitted from the server to the cache, only one copy
>is stored at the cache, and the cache need not do any more conditional
>GETs unless new User-Agents appear.
>
>If the proxy is "cooperative" (as we define in our proposal), then
>when it finally removes this entity from its storage, it would have
>to send
>
>	HEAD /foo.html HTTP/1.1
>	User-Agent: Lynx
>	Cache-control: use-count=97
>
>	HEAD /foo.html HTTP/1.1
>	User-Agent: Mosaic
>	Cache-control: use-count=13
>
>(but of course these can be sent in one TCP packet, since we
>are presumably using persistent connections).
>
>-Jeff
>
>
>
Received on Friday, 9 August 1996 17:34:14 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:06 EDT