On Saturday 01 September 2001 11:20, Graham Leggett wrote:
> Ryan Bloom wrote:
> > > The core question is whether we store data in the cache with transfer
> > > encodings already applied.
> >
> > I would put it before the content encodings, but after the content
> > filters. My reasoning is simple. Content encodings tend to be fast, but
> > content filtering tends to be slow. Cache the slow stuff, ignore the fast
> > stuff.
>
> But from a keep-it-simple point of view, if we make the cache the very
> last filter, and then make it behave exactly like a transparent cache,
> then we have a good chance that it will "just work", because the HTTP
> protocol defines the correct behavior already and transparent caches are
> widely deployed.
>
> If we start moving it up and down the filter chain, we're likely to
> introduce some nasty what-if's that we have not encoutered before.
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. That is a waste of space in the server, and chunking and byterange are
incredibly cheap operations with bucket brigades. We have very well defined
locations for filters, and if somebody tries to modify the content after the start of
the HTTP_HEADER_FILTER ftype begins, the cache will be the least of our
problems.
Ryan
______________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
--------------------------------------------------------------
