DO NOT REPLY [Bug 31226] New: - AddOutputFilterByType deflate not active with mod_proxy

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31226>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31226

AddOutputFilterByType deflate not active with mod_proxy

           Summary: AddOutputFilterByType deflate not active with mod_proxy
           Product: Apache httpd-2.0
           Version: 2.0.50
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: mod_deflate
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: fbregier@webmails.com


I use Apache 2.0 to have a reverse proxy web server that
compress with mod_deflate the web pages in direction of the users.
Applications behind (on application "proxified" server) generate :
- text/html document
- application/pdf or others like jpg document 
both using an url such as http://myreverseproxy/application/application.exe
or application.php whatever like this.

The url is always the same for one application, only the context (session)
implies the answear (html or pdf document).
We want to compress document with type mime = text, but not those
with jpg or pdf type mime.

But here is the problem, with proxypass and proxypassreverse :

1) using SetOutputFilter DEFLATE implies that everything is compressed
even if the mime type is a pdf or jpg since the exclusion can be based 
only on url, which is not possible here.
We can exclude files like http://myreverseproxy/application/image.jpg
but not the same jpg create dynamically by 
http://myreverseproxy/application/application.exe

2) using AddOutputFilterByType DEFLATE text/html text/plain
compressed nothing at all, neither html neither pdf or jpg.
And accordingly to the documentation and sources on the web,
this second solution should be the correct one.
Every mime types are defined and ok, the returned documents
are using the correct mime type (text/html, application/pdf, ...).

I found not much information on the web on a reverse proxy with
compression at the same time.
It is quite a big problem for us since we cannot use
the web compression in this conditions.
Has someone have this problem too ?
What can I do to correct this ?

thank you for your help

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org