Skip to main content

Double GZIP compression problems.

2 replies [Last post]
Anonymous

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.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
oleksiys
Offline
Joined: 2006-01-25
Points: 0

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.

Lachezar Dobrev

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