httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Axel-Stephane SMORGRAV" <>
Subject RE: [users@httpd] mod_filter being ignored (ProxyReverse, IIS Backend forced deflate content)
Date Thu, 27 Dec 2007 10:30:22 GMT
Maybe I am being a little naive, but I am very surprised that IIS compresses the contents without
adding a Content-Encoding header to the response in which case you your browser should be
able to decompress it. It seems more likely that there is an application that generates compressed
contents without adding the required headers.

Having a correct Content-Encoding header in a response may not be enough, however. There used
to be problems with IE not decoding contents before passing it to plug-ins like SVG or PDF.
I specifically remember that at some point the implementation of the SVG plugin changed so
it was able to recognize compressed contents and decompress it instead of the browser doing
so. Maybe that is what you are up against. We will not know unless you are a little more specific
about the kind of contents that you are not able to browse correctly and the headers in the

The Content-Type of the respone could also be wrong thereby preventing the contents to be
displayed by the appropriate plug-in.

Finally, try replacing

       FilterProvider myfilter inflate req=Accept-Encoding *


       FilterProvider myfilter inflate req=Accept-Encoding !$.

-----Message d'origine-----
De : Guzman Braso [] 
Envoyé : jeudi 27 décembre 2007 08:05
À :
Objet : [users@httpd] mod_filter being ignored (ProxyReverse, IIS Backend forced deflate content)

Hello everyone,

This is the problematic setup:

1. Windows Client behind any proxy (client proxy) software.
2. Apache 2.2.3 (64bits) as reverse proxy.
3. IIS as backend server forcing deflate compression on *some* content.

Well... as the windows clients are behind a proxy, no matter what I do, the client will always
send the requests to me with Http 1.0 which is default setting for most windows proxies server
out there. Then, apache will forward this request to the backend server. The backend server,
no matter which http version I tell, which encoding I tell, will ALWAYS force some dynamic
applications to return content compressed as "deflate".

The result? Well, the result is Internet Explorer showing the content compressed without inflating
first, which means it shows all garbage.

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message