Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a mod_ext_filter to replace the statics image url and mod_deflate to compress the web.

If I use this two module separate and everything work fine.

(1. Replace content ok and no compress 2. Compress content but no replace url)

But if I use both module, then I got garbage and the response header not have gzip but have Transfer-Encoding: chunked.

Can anyone help me about this? which way should I try to solve where ? Thank you.

share|improve this question
    
same problem here .. this has to do with the order in which the filters get executed, but i am not sure how to set the order, so that mod_ext_filter gets executed first and mod_deflate after that –  freethinker Aug 8 '11 at 9:15

2 Answers 2

I ran across this myself. No combination of INFLATE, DEFLATE and my custom filter would work. It seemed to always perform the gzip DEFLATE before handing off to my customer filter.

I'm using Apache 2.2.2. So essentially, when a gzip encoded response was received (reverse proxy mode) and passed along to my custom filter phpFilter:

ExtFilterDefine phpFilter mode=output \
cmd="/path/my_php_filter.php"

This works just fine (I receive nice decompressed stuff, regardless of Content-Type):

SetOutputFilter INFLATE;DEFLATE

This also works (I see nice compressed stuff, or nice uncompressed stuff for non-gzip response like JSON or HTML):

SetOutputFilter phpFilter

But this doesn't work! the STDIN to my php script would always be garbled when the Content-Type was gzip.

SetOutputFilter INFLATE;phpFilter;DEFLATE

After a TON of Googling, and a little luck, this ended up working for me. I don't know why it's necessary, but adding proxy-html into the filter chain seems to force my custom filter to execute before DEFLATE.

SetOutputFilter INFLATE;phpFilter;proxy-html;DEFLATE

I know I'm answering this question 2 years too late, but hopefully this saves a day or two of headache for the next person.

share|improve this answer

I also just came across this:

so maybe adding ftype=N>21 would also work

# Trace the data read and written by mod_deflate
# for a particular client (IP 192.168.1.31)
# experiencing compression problems.
# This filter will trace what goes into mod_deflate.
ExtFilterDefine tracebefore \
cmd="/bin/tracefilter.pl /tmp/tracebefore" \
EnableEnv=trace_this_client  

# This filter will trace what goes after mod_deflate.
# Note that without the ftype parameter, the default
# filter type of AP_FTYPE_RESOURCE would cause the
# filter to be placed *before* mod_deflate in the filter
# chain. Giving it a numeric value slightly higher than
# AP_FTYPE_CONTENT_SET will ensure that it is placed
# after mod_deflate.
ExtFilterDefine traceafter \
cmd="/bin/tracefilter.pl /tmp/traceafter" \
EnableEnv=trace_this_client ftype=21

<Directory /usr/local/docs>
SetEnvIf Remote_Addr 192.168.1.31 trace_this_client
SetOutputFilter tracebefore;deflate;traceafter
</Directory>
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.