Re: Re: [PEPr] Comment on HTTP::HTTP_Cache
| From: | anatoly techtonik | Date: | Wed, 08 Dec 2004 16:50:46 +0000 |
| Subject: | Re: Re: [PEPr] Comment on HTTP::HTTP_Cache | ||
| References: | 1 2 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-34913@lists.php.net to get a copy of this message | ||
Hello Stephan,
In HTTP 1.1 specification Last-Modified, Etag, Content-Length and Content-MD5
form a unified mechanizm for cache control. It would not be effective
to work with these on a separate basis. It would be interesting to get
a universal solution. For example what will happen if you set Etag and
server sets different Last-Modified? It would be nice to read highly
technical draft or RFC of this package algorithm taken the following
document into account: http://www.faqs.org/rfcs/rfc2616.html
More precise - chapter > 13.1.3 Cache-control Mechanisms
Also some tests would be nice, because it would be easier to prove that this
package actually works on most servers/clients, or to determine if it
doesn't work. This proof can be derived from HTTP RFC analisys, but
in that case the output should look like an RFC too. =)
If this package is intended to do what I think - to control cache on
the user's side - then I'd more prefer it to be named like HTTP::Cache_Control
SS> Davey Shafik schrieb:
>> Seems to me that this package is kinda pointless. From the description of
>> it on your blog, an MD5sum of the output is used to determine the
>> viability of a cached item...
>> If its not done on the output, then how can you tell if its changed? i.e.
>> echo $_GET['name']; will be the same always in PHP code, but not in the
>> output it shows.
>> This means that the code must always be executed - thus, saving you
>> nothing.
SS> For one, it saves me about 10GB of traffic per month on the sites I
SS> maintain :) And this means, it saves some users time.
SS> There are two ways two use it:
SS> 1. You are not having performance problems and only want your users to
SS> have faster access to your site. HTTP_Cache will make sure that the same
SS> data is not transferred twice a user reloads the page.
SS> This can be done with only instantiating the class.
SS> 2. If you already have a cache system, that is able to uniquely identify
SS> a page by a cache key, you may as well use this unique cache for
SS> HTTP_Cache and thus can check, whether the user already has the page
SS> content in his browser cache. When generating this cache unique cache
SS> key, you normaly compile a list of all external variables (cookie,
SS> session, user input, calculated stuff, etc.) and create an md5 sum for
SS> this. I have sites where I have thousand copies of the same page in my
SS> server-side cache, all of them have slight differences...
SS> HTTP_Cache caches data on the client, for serverside caching use Cache
SS> or Cache_Lite. Of course you can also easily combine both.
SS> Hope this makes it a bit clearer,
t
--