Re: Features

From: Donovan Baarda <>
Date: Tue, 25 Nov 1997 12:49:08 +1100 (EST)

On Tue, 25 Nov 1997, David J N Begley wrote:

> On Tue, 25 Nov 1997, Donovan Baarda wrote:
> > 3) the object is only decompressed before sending to the final client, or
> > even better, by the client itself.
> Whilst it would be better for the client to decompress objects itself,
> there aren't that many clients (any?) which could be easily configured to
> do this today - that leaves us with the final proxy in a hierarchy doing
> the compression before passing the object on to the client; thus, my
I think you mean decompression, which is less intensive than compression.

> question...
> How does the proxy know (accurately) it's talking to an "end-user
> client" as opposed to a child proxy requesting an object via HTTP?
I never said it would be easy :-)

> I can see a circumstance wherein objects passing through a hierarchy keep
> being compressed and decompressed unnecessarily...

If they were poorly configured, yes.

> Someone mentioned that HTTP/1.1 permitted compression as an option -
> perhaps all effort should be put into making Squid fully
> HTTP/1.1-compliant, and thus implementing compression that way? At least
> there'd be a bigger chance of getting the decompression code into the
> clients that way.
Using HTTP/1.1 compression is a logical choice for client compatablility,
but I hope the compression algo's it uses are fast :-)

The initial glance at how to implement this suggests compressing the
objects when they are sent, and decompressing them when they are received.
This would be pretty CPU intensive, and waste disk space.

A better way is to store the objects compressed, forward them compressed
to clients that can handle it, and uncompress them for clients that can't.
If you are lucky you can request them compressed from the HTTP/1.1
compliant source and save yourself the compression overhead. To save
yourself compressing every hit for HTTP/1.1 clients, it would pay to
compress uncompressed objects fetched before storing them.

This would be nice for the CPU loaded top-level caches. They would not
need to compress or decompress anything, because compression would be done
by the source, and decompression by the client.

finger for more info, including pgp key
Received on Mon Nov 24 1997 - 17:57:41 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:37:43 MST