Re: Re: [PEPr] Comment on HTTP::HTTP_Cache

From: 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 --

« previous php.pear.dev (#34913) next »