Re: Preventing a double gzipping
Alvaro Lopez Ortega <alvaro <at> octality.com>
2010-01-05 18:07:28 GMT
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/
RSS Feed