[users@httpd] mod_filter being ignored (ProxyReverse, IIS Backend forced deflate content)

[Guzman Braso <gu...@gmail.com>]

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.

Things I've tried and the results I got:

A. Removing set http 1.0 by force for IE.
Even when doing this and having apache responses go with HTTP 1.1 to
IE, IE keeps sending requests with HTTP 1.0.
So it didn't help at all.

B. Checked http headers of both Mozilla & IE
The single difference on the headers return by apache to the client
are the http protocol version.
The main difference in the headers sent by the client, is that as IS
is using HTTP 1.0, is not sending Accept-Encoding as well many other
HTTP 1.1 headers.

C. Use mod_filter to inflate the deflated content before returning to users
Tried with mod_filter to tell to inflate the content to any  user not
sending a request with a propper Accept-Encoding.
I was compeltely unable to get this to work, and this is the main
reason of being writting to the list.
I've read every mail on google related to mod_filter usage and it
seems what's good for others don't work on my configuration, already
verified mod_filter is being loaded (httpd2 -M show it).
I'm putting the following directives inside the same virtualhost that
define the reverse proxy, tried putting it before & after the
ProxyReverse without luck:
       FilterDeclare myfilter CONTENT_SET
       FilterProvider myfilter inflate req=Accept-Encoding *
       FilterProtocol myfilter "change=yes proxy=transform"
       FilterTrace myfilter 1
       FilterChain myfilter

Of course at first FilterProvide match wasn't an * but even with an *
it doesnt apply. NEVER.
I've not been able to see a SINGLE line of mod_filter even after using
the FilterTrace directive.
So it's clear to me that if there's a way out of my problem is through
mod_filter usage.
What I'm missing? It seems like my Filter directives are ignored,
however no warning in any log are generated, and I tried to put a typo
in the directives and apache complains inmediatly, so I'm sure it's
reading it and it evaluates the directives. However it ignores my
instructions.

The worst part is that this same scenario, using an IIS as reverse
proxy, was working good with clients behind proxies (clients proxies).
I bet the IIS acting as reverse proxy was uncompressing the compressed
content before returning it to users who requested HTTP 1.0 in the
headers.

I'm really out of ideas, please help, any idea will be much appreciated.

Kind Regards,

Guzmán Brasó

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

RE: [users@httpd] mod_filter being ignored (ProxyReverse, IIS Backend forced deflate content)

[Axel-Stephane SMORGRAV <Ax...@europe.adp.com>]

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 responses.

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 *

with 

       FilterProvider myfilter inflate req=Accept-Encoding !$.

-ascs
 
-----Message d'origine-----
De : Guzman Braso [mailto:guzman.braso@gmail.com] 
Envoyé : jeudi 27 décembre 2007 08:05
À : users@httpd.apache.org
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:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org