-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
On 3/20/2009 8:02 AM, André Cruz wrote: > I'm running apache 2.2.9, mod_jk 1.2.27 and tomcat 6.0.18 and I get this > problem > as well: > > GET /shibboleth-idp/SSO HTTP/1.1 [snip] > HTTP/1.1 302 Moved Temporarily > Date: Fri, 20 Mar 2009 11:11:24 GMT > Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8c mod_jk/1.2.27 > Location: https://sso1.sso.bk.sapo.pt/Login.do?to=%2Fshibboleth-idp%2FSSO > Vary: Accept-Encoding > Content-Encoding: gzip > Content-Length: 20 [snip] > Notice that it tried to compress an empty response and it enlarged to 20 > bytes. > But this seems more like a problem with mod_deflate. gzip has a minimum output size (apparently 20 bytes). A gzip stream has to have a header, etc. to identify it as a gzip stream and allow decompression, even when there is no data to be compressed. I would agree that mod_deflate should detect zero-length content and just drop the compression, but if mod_deflate is engaged before the content is generated, it can't predict that you will have a zero-content response. You'll probably just have to live with this. At least 20 bytes isn't much. You have much more data in your headers than you do in your compressed emptiness (even the Content-Encoding header is more than 20 bytes). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAknDpjsACgkQ9CaO5/Lv0PCzMQCgnUVJzInZHhDPfekqUWZb/cOe 9UcAn07A8qiSdyRQa9IygEJFxk7jbZGN =vSuM -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org