Home » HTTP » HTTP_Download » Bug #4540

[2005-06-07 01:52 UTC] aron-pearphp at sightspeed dot com

Description:
------------
In the HTTP download code, if the developer wants to enable caching for the object, the code currently adds the following header:

Cache-Control: public, must-revalidate, max-age=0

This results in the file/content not being cached because a max-age of 0 means the content is valid for 0 seconds from now.

Reproduce code:
---------------
Ideally, the developer should be able to set the max number of cache seconds in the class. However a change of the code to read

max-age=2600000

will cache for slightly longer than 30 days.

3600 is cache for one hour.

Expected result:
----------------
According to the RFC: max-age should be the following:

<exerpt from rfc 2616>
The client can specify these three kinds of action using Cache- Control request directives:

End-to-end reload
The request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field names MUST NOT be included with the no-cache directive in a request. The server MUST NOT use a cached copy when responding to such a request.
Specific end-to-end revalidation
The request includes a "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate its own entry, if any, with the next cache or server. The initial request includes a cache-validating conditional with the client's current validator.
Unspecified end-to-end revalidation
The request includes "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate its own entry, if any, with the next cache or server. The initial request does not include a cache-validating
conditional; the first cache along the path (if any) that holds a cache entry for this resource includes a cache-validating conditional with its current validator.
max-age
When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with the cache entry. In this case, the cache MAY use either validator in making its own request without affecting semantic transparency.
However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated copy to the client with a 200 (OK) response. If the server replies with a new entity and cache validator, however, the intermediate cache can compare the returned validator with the one provided in the client's request, using the strong comparison function. If the client's validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) response.
If a request includes the no-cache directive, it SHOULD NOT include min-fresh, max-stale, or max-age.

< / end>

Note the section about how max-age=0 forces each cache to revalidate its entries. This means that it must refetch the content thus avoiding the purpose of caching.

Changing the value has been tested through ethereal dumps of http transactions after modifying the code.