Re: Features

From: Gregory Maxwell <nullc@dont-contact.us>
Date: Mon, 24 Nov 1997 19:26:22 -0500 (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
     ^de
> question...

There should by acls for compression, we dont want to compress .jpgs..

The lzo compression alg I suggest has increadibly fast decompression..
In fact.. Reading a compressed file off the disk and decompressing it on
the fly, will be faster then just reading the uncompressed file off the
disk... On a single cpu of my 166MMX box lzop decompresses at a bit under
30megs a second.. So unless you have a really mega raid.....

> 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?

User agent the http/1.1 x-compressed tag..
 
> I can see a circumstance wherein objects passing through a hierarchy keep
> being compressed and decompressed unnecessarily...
>
> 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.

See squid 1.2 :)
Received on Mon Nov 24 1997 - 16:31:40 MST

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