Re: squid adding gzip support

On Thu, 2003-08-14 at 23:48, Gonzalo Arana wrote:
> Hi,
>
> Thanks Henrik and Robert for all of your suggestions (particularly hints
> of where to patch squid-2.5, and about rfc2616, 215 warning).
>
> New issues about this:
>
> 1) When to compress:
> a) Client must have sent Accept-Encoding: and gzip has to be listed
> in supported encodings ('compress' could be implemented with not
> too much effort).

Thats one necessary condition. Additionally there are many bugs in
browsers relating to CE support. See the mod_gzip list for numerous
examples.

> b) Server response should not be Transfer-Encoding: chunked. If it
> is, it should be de-chunked, right?

It can't be chunked - 2.5 cannot make 1.1 requests, and 1.1 servers are
not allowed to send TE content to 1.0 clients.

> c) Content-type of answer is text/html or text/plain (this could be
> moved to gzip_access, I think).

Yeah - this would be user driven I think.

> d) Answer from server is not already compressed :-).
> d) Server response does not contain Content-Range header (in case of
> a miss). I simply won't compress partial data. This is due to
> the fact that Ranges header usually is used on 'resume download'
> operation, and I want to speed up interactive navigation.

You -cannot- compress server range responses. They are either already
compressed, or not. The only thing you could do is grab the whole
object, compress, and then offer the sub-set. You *will* need to do Etag
matching for any range logic that occurs. ( To ensure object consistency
on the client).

> e) gzip_access (new directive) is ok
> I will add this in order to enable compression only on dial-up
> clients (slow clients).
> Is this ok?

Something like this yes. I'd suggest that gzip access is to board:
response_ce_negotiation on
response_ce_gzip_access ...

would be specific enough.

> 2) Where to compress:
> I will compress on comm_write.
> Thank you very much for your wise adivce.
> I have to check where to start compressing, since comm_write only
> gets data to be written (other wise, headers will be compressed to).
> Would it be OK to add something like this to struct _fde? (I mean,
> is it the right place?).

The connection struct, or the clientHttpRequest struct is the right
place.

> 3) Which squid to patch:
> Unless squid 3 is going to be STABLE next week, I have to work on
> squid 2.5, since I have a deadline of 1 month to accomplish this :-(
> Of course, Once this is working, I will start working on a patch
> for squid3.

squid-3.0 has only two open bugs, and they are both AFAIK fixed already
- we are just waiting for confirmation.

> 4) Answer modification:
> a) Should I alter Vary header (by adding Accept-Encoding)?

Absolutely. In fact, you SHOULD vary on every header that is evaluated
in the access rules that determine compression or not.

> b) ETag: May I build it from md5sum of compressed content?

Certainly.

Cheers,
Rob

-- 
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.