Ah. This is a known issue... Sorry to bother.
I checked, and found the original conversation in my mailbox :-/
Will this patch apply to AJP/JK connector too?
I am a bit reluctant to apply the patch to the production server.
For the time being I left the request decoding only, and left the
response encoding to Glassfish.
2013/2/25 Oleksiy Stashok <oleksiy.stashok_at_oracle.com>:
> Hi Lachezar,
>
> pls. take a look a this thread [1]
>
> WBR,
> Alexey.
> [1] http://forums.java.net/node/892262
>
>
> On 25.02.13 05:39, Lachezar Dobrev wrote:
>>
>> Dear colleagues.
>> I've come to a very weird situation. In my application I am using a
>> GZIP compression filter, that supports compression for both requests
>> and responses. I've also set up compression on the Glassfish side in
>> the HTTP/JK connector. Unexpectedly for me Glassfish does not seem to
>> understand that the stream is already compressed, and compresses it
>> again.
>> I am not familiar with Glassfish code, so I am not able to provide a
>> patch proposal.
>> I propose that the component responsible for compressing the output
>> checks if the response contains the 'Content-Encoding' header, and
>> skip compression if the application has already provided
>> application-level content encoding.
>
>