Forum Moderators: phranque

Message Too Old, No Replies

Deflated redirects

Any downside to using gzip with 301/302?

         

bcc1234

7:05 pm on Oct 17, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



In my current configuration, Apache compresses the output if the client supports it.

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.

jdMorgan

7:30 pm on Oct 17, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I dunno, but this may indicate that the compressor is mis-configured, in that it should be using the filetype, not the URL, to determine whether to compress or not. Since a redirect (or error) does not actually resolve to a specific file, it should not be compressing these.

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

bcc1234

7:49 pm on Oct 17, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Yep, I have Apache configured to compress by content-type. (only text/html) Not but file name.

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.

bcc1234

7:51 pm on Oct 17, 2008 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



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.