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

Paul Leach:
>
>Mentioning 200 (OK) responses is duplicative of text elsewhere in the
>spec, and does not include other cases that are allowed to be cached.
>Sections 13.14 and 10.7.2 give the rules for what may and may not be
>cached. This section should just say "cacheable responses" and cross-ref
>those sections.

OK.

>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'.

>Finally, this section actually gives the cache replacement rules for
>both varying and non-varying resources, so it might better be titled
>simply "Cache Replacement".

OK.

>
>A replacement section 13.20 is appended.

I append a replacement replacement section 13.20 after that.

>
>Paul

Koen.

>===================
>>
>>   13.20 Cache Replacement
>>
>>   If a new cacheable response (according to the rules in
>>   sections 10.7.2 and 13.14) is received from a non-varying resource
>>   while an old response is cached, caches SHOULD delete this old
>
>>   response from cache memory and insert the new response.
>>
>   If a cache has a cached response for a varying resource 
>>   with a certain variant-ID, and
>>   receives, from the same resource, a new cacheable response which has
>>   the same variant-ID, this means that the old response SHOULD be
>deleted from the 
>>   cache and replaced by the new response.
>>
>>   Note: The variant-ID mechanism cannot cause deletion from cache
>>memory 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.
>>

First change-barred version: the change-bars are computer-generated,
and reflect changes with respect to the 1.1-02 draft.

   13.20 Cache Replacement

|  If a new cachable response is received from a non-varying resource
|  while an old response is cached, caches can delete this old response
|  from cache memory and insert the new response: this recycles cache
|  memory space.  For cachable responses from varying resources (Section
|  10.vary), cache replacement is more complex.

   HTTP/1.1 allows the authors of varying resources to guide cache
|  replacement by the inclusion of variant-IDs in the responses of these
|  resources. [##lots of complexity deleted here##] If a cache has
|  stored in memory a cachable response with a certain variant-ID, and
|  receives, from the same resource, a new response which has the same
|  variant-ID, this should be interpreted as a signal from the resource
   author that the old response can be deleted from cache memory and
   replaced by the new response.

|  The variant-ID mechanism cannot cause deletion from cache memory 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.


Second change-barred version: the change-bars are computer-generated,
and reflect changes with respect to the rewrite I posted earlier.

|  13.20 Cache Replacement

|  If a new cachable response is received from a non-varying resource
|  while an old response is cached, caches can delete this old response
|  from cache memory and insert the new response: this recycles cache
|  memory space.  For cachable responses from varying resources (Section
   10.vary), cache replacement is more complex.

   HTTP/1.1 allows the authors of varying resources to guide cache
   replacement by the inclusion of variant-IDs in the responses of these
   resources. [##lots of complexity deleted here##] If a cache has
|  stored in memory a cachable response with a certain variant-ID, and
|  receives, from the same resource, a new response which has the same
   variant-ID, this should be interpreted as a signal from the resource
   author that the old response can be deleted from cache memory and
   replaced by the new response.

   The variant-ID mechanism cannot cause deletion from cache memory 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.


Koen.

Received on Wednesday, 1 May 1996 15:50:53 UTC