On 05/01/2010, at 18:38, Stefan de Konink wrote: > My suggestion would be informing the mimetype list with the fact that a > mimetype or extention is already compressed. And not apply the deflate > or gzip algorithm again on this file. The file is served with the > specified content type, thus a .gz as gzip, a kmz as > vnd.google-earth.kmz. But these types will not be 'recompressed'. > > Additionally I would suggest not to send the compressed version if the > compressed version equals or exceeds the uncompressed filelength + > compression header.
I'm just thinking.. Currently, Cherokee allows to define whether or not the content matched by a rule should be gzipped. There is a checkbox under the “Allow GZip” that can be turn on and off. If we changed that, and instead it showed two options like ‘allowed’ and ‘forbidden’, you could add a rule to stop kmz files from being encoded. Content would only be encoded when gzip is set to allowed and the client requested so. However, if a ‘forbidden’ entry were find while evaluating the rules, the server would never encode the reply even if a later rule tried to activate it later on. For instance: - Extension kmz, Gzip ‘forbidden’ - Extension /download, Gzip ‘allowed’ In this case, http://example.com/download/foo.kmz would not be gziped. It's quite similar to the current mechanism, but somehow slightly more flexible. This change would be a positive improvement, although I still feel like it is not enough. How is the rest of the servers work at this respect? That'd be a good starting point.. -- Octality http://www.octality.com/ _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
