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>.
signature.asc
Description: This is a digitally signed message part
