Forum Moderators: phranque
I noticed that that results in redirects also getting compressed. Empty content still gets passed through gzip.
The redirects that only contain HTTP header and no content, result in 20 bytes of compressed content.
Is there any downside to leaving it this way?
Are there any user agents that can't deal with compressed redirects?
I don't care about CPU overhead on the server and the extra 20 bytes of data transfer. I'm just wondering if I could be losing some visitors because some browsers can't handle it correctly.
Note that I'm making a distinction here between the URL and the file in the machine's filesystem that it resolves to. In the case of an error or a redirect, it is accurate to say that the URL does not resolve to any file; These handlers are invoked before the content-delivery phase of the Apache API is started.
The Web being what it is -- full of software shipped to meet deadlines rather than when it's completely-finished and tested (Ship it! Ship it! -- We'll issue an online patch or service pack later!), I'd recommend against compressing anything but HTML, XML, and other highly-compressible "documents." There should already be "hooks" for filetype selection in the compression software since, for example, there is nothing to gain from trying to compress pre-compressed formats such as JPEG and MP3; Trying to compress these filetypes is a waste of CPU time. Also, the compressor should have a minimum filesize which it will compress: Anything smaller than one (or a few) TCP/IP packet(s) is simply not worth bothering with.
YMMV -- I take a "lowest common denominator" approach to many things, and this is one of them. :)
Jim
But my application server sets the content type to html even for redirects. I can strip the header within the app server or force apache not to compress certain file names (that match the redirects).
But I'm not sure if there is any need to do that or not.
That's what I'm trying to figure out.
Also, the compressor should have a minimum filesize which it will compress
Don't think so. The content gets flushed as soon as it's produced. So Apache doesn't know the final size of the output until the stream for that request has been closed. Those are not static files, but output from an application server.