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

RE: EDITS for Section 13.20 (Cache Replacement for Varying Resources)

From: Paul Leach <paulle@microsoft.com>
Date: Wed, 1 May 1996 16:55:09 -0700
Message-Id: <c=US%a=_%p=msft%l=RED-77-MSG-960501235509Z-31444@tide19.microsoft.com>
To: "'koen@win.tue.nl'" <koen@win.tue.nl>
Cc: "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
>----------
>From: 	koen@win.tue.nl[SMTP:koen@win.tue.nl]
>Sent: 	Wednesday, May 01, 1996 3:31 PM
>
>
>>Furthermore, sections 13.11.2 and 13.11.3 say that caches SHOULD only
>>return the latest response received; hence a new cacheable response
>>SHOULD replace an older cached one -- a little stronger than "guidance".
>
>I do not agree.  The spec can't tell a cache when to delete a response
>from memory internally, it can only tell the cache when not to return
>it anymore.  The section talks about cache memory management, and can
>therefore only talk in terms of `can' and `guidance'.

I agree with you that it can't demand that the cache delete the cached
copy. It can demand that it not be returned, and that *is* more than
guidance. Your suggested rewrite doesn't capture the "must never return
the old one" requirement.

I claim that in the context of a protocol spec, all that any statement
about what a cache should do to its internal state can mean is this: as
far as _externally visible behavior is concerned_ it must appear as
though it had done that to its internal state. What it does inside is
its own business. Hence, I disagree that we can't frame rules in terms
of instructions to do things to its internal state.

I havbe appended a new new new replacement for 13.20.

Replacement for 13.20
>==================================
>
>   13.20 Caching Responses
>
   If a new cacheable response (see sections 10.7.2, 13.11.2, 13.11.3
>and 13.14) 
   is received from a non-varying resource while an old response for the
same 
   resource is cached, the cache SHOULD insert the new response into
cache storage 
   (see section 13.7.3).

>   If a new cacheable response is received from a varying
   resource with a certain variant-ID while an old response with the
same
>   variant-ID for the same resource is cached, the cache SHOULD insert
the new
   response into cache storage.

   The cache SHOULD now use the new response to reply to this request
and to any
   future requests that would previously have caused the old response to
be 
   returned.

	Note: In some cases, this may mean that the cache chooses to delete the
old
>	response from cache storage to recover space.
>
   Note: The above mechanism will not trigger deletion from cache
>storage of old
>   responses with variant-IDs that will no longer be used.  It is
>expected
>   that the normal 'least recently used' update heuristics employed by
>   caches will eventually cause such old responses to be deleted.
>
>|  All responses from varying resources SHOULD include variant-IDs.  If
>|  these are not present, the resource author can expect caches to
>|  correctly handle requests on the varying resource, but cannot expect
>|  the caching to be efficient.
>
>
Received on Wednesday, 1 May 1996 17:02:34 EDT

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