Re: cvs commit: httpd-2.0/modules/experimental mod_cache.c

[William A. Rowe, Jr.]

From: "Graham Leggett" <[EMAIL PROTECTED]>
Sent: Monday, September 03, 2001 11:30 AM


> Ryan Bloom wrote:
> 
> > But keeping it simple would essentially make the cache less useful.  If I request
> > a pdf file using three different browsers, the server will most likely have three 
>different
> > copies of the same file.  One with byteranges, one with chunks, and one with
> > neither.
> 
> This returns to the point about whether the cache should store data with
> the transfer encodings applied, or not.
>
> I think that the cache should store data *without* transfer encodings
> applied: Ie not chunked and not byteranged. This solves your problem.

WFT?!?  I've been letting this conversation slide (to avoid IO) but this is
absurd.  OF COURSE you don't apply transfer mechanics (e.g. byteranges, chunking
etc) to a cache!!!  They aren't reusable - they are likely meaningless to any
other request.  You will waste more time searching the cache than you save with
occasional hits to it.

A transfer encoding isn't a byterange or chunking output.  It's a compression
scheme, and that we _want_ to cache, to avoid the cpu overhead.

Handler (e.g. Core/autoindex/mod_webapp etc)
 V
Includes and other Filters
 V
Charset Translation (Transform to Client's preference)
 V
Content Encoding (gz) (Body - large packets - higher compression)
 V
 X <<< cache here
 V
Byterange
 V
Chunking
 V
Headers
 V
SSL Crypto
 V
Network I/O