Re: [PEPr] Proposal for HTTP::HTTP_Cache

Guess I was a bit surprised when I read the post on Planet PHP, guys, you know it's holiday down here :) Nevertheless I've got a few thoughts on that proposal... So, what's the problem with HTTP_Header_Cache and HTTP_Cache? As already mentioned, HTTP_Header_Cache just uses the Last-Modified header and collegues to calculate validity and staleness, which is pretty fine as long as you serve unpersonalized content. The "last modification" is a weak entity, where the real payload actually is not validated to *not* have changed. The "ETag" is a strong entity which can extinct this deficiency, but for generating an ETag you need to know the actual body for validation. This means mainly the following conclusions to me: - The weak entity (i.e. Last-Modified) is fine as long as you serve unpersonalized content. It provides bandwith and CPU time savings. - The strong entity (i.e. ETag) can be used for unpersonalized as well as personalized content, because the ETag is validated against the actual body. This means that caching by ETag can (mostly) only save bandwith, because one needs to know the entity from which the ETag is adhered, and the entity is usually generated at run-time. - One could use HTTP_Download do accomplish caching by ETag (while those routines may not be stable!), which has evolved to kind of a HTTP_Response package, with some features that would have been better split off. One thing I never came around to implement is HTTP_Download_BLOB (volunteers?) that handles database blobs with a (sort of) stream interface. After all, I'm not anxious of a feature-rich, well-thought and separate HTTP_Cache package. It just shouldn't be yet-another-quick-shot. Maybe the implementor(s) should also have a look at Hordes Browser package and its header routines for any browser quirks that might affect HTTP caching and have already been revealed. Ok, so this became a rather long statement, but you can get a quite longer if you just head over to the HTTP protocol RFC, worth a look if you're interested (actually not meaning any particular person). Regards, Michael ps: I also think that PHP itself could provide a lot more functionality

     regarding HTTP while it claims to be the best web scripting language.