Re: transparent output compression patch

Hello Jade, On 12-Nov-00 19:12:00, you wrote: >Bugs/TODOs: > 1. Grep for them (TODO|FIXME). > 2. The deflate coding dosn't work. I don't see why, right now... hint? In theory checking if the Accepting-Encoding: request header would be enough to figure if compression is acceptable in the requesting browser (or proxy server). The truth is that it isn't that simple. There are plenty of circumstances where it may not work and the end user will only see a blank page. If you look into Remote Communications mod_gzip source code they explain some of the circumstances where it does not work. Oddly they seem to not handle those situations. That suggests that they may want people to complain so they can sell their commercial solution. Anyway, there seem to be other situations that they admitedly did not seem to know, like proxy servers that choke on character 0 (NUL) in a Content-Type: text/html stream. Many free access ISP use proxy servers and they now represent a significative market share in many countries. I don't know if some could not be using broken proxy servers to make all this that hard to handle. Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org -- E-mail: mlemos@acm.org URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp --