Re: [PEPr] Comment on HTTP::HTTP_Cache

Hi,

This proposal is senseless as it states. The cache headers are far to be complete. Please take a look at the HTTP::Header (as stated by Ian) package from As stated before, this code saves me 10 GB of traffic per month, so it is not senseless.

Wolfram. It also requires some enhancement to work with some broken browsers but it's already far better and already exists since quit a long time. HTTP_Header_Cache is not soemthing I would call far better than my proposal. It does not provide any functions to work with ETags and thus I cannot use it in my pages. I cannot force a cache for a certain amount of time, I need to use a unique identifier for my pages which depends on cookies, sessions and any external parameters. So only Etag-based-caching will work.

Please transform this proposal into a patch for HTTP::Header and take a look about what some can need to work with HTTP Headers and cache. I'm well aware what HTTP caching can do and how it works. The proposal already states that support for Last-Modified headers will be implemented.

I also already stated, that I'd be willing to merge this package with the functionality provided by HTTP_Header_Cache, but I'd like to make some API changes (as HTTP_Header_Cache was designed with HTTP caching based on the last modified time in mind and even exits in the conctructor) and create a new package that is independent of HTTP Header. Searching for "cache" on pearweb will not point you to the HTTP_Header package, so this package is too hard to find. This is not meant as an offense to Mike and Wolfram, but I think all functionality combined in a new HTTP_Cache package would be the best solution. Furthermore, HTTP_Header_Cache is targeted at saving processor time and bandwidth as you use it at the front of your script and exit if the cache is valid. With my package you can use output buffering to save bandwidth in *all* of your pages even if it's not possible to save processor time by including and instantiating in an auto_prepend file. All this has been stated in my replies to previous comments. Best regards, Stephan