Skip to main content

Glassfish double compression

9 replies [Last post]
arosso
Offline
Joined: 2010-02-19
Points: 0

We've recently upgraded from Glassfish 2.1 to 3.1.2.2 and are finding issues where Glassfish double compresses output (or at least that is what I assume is happening).

We deploy some WARs that already have Servlet Filters which take care of GZip compression. We also are using Tuckey UrlrewriteFilter to do some Url rewriting and this filter also seems to do Gzip compression. For both these cases we cannot switch off the compression behavior easily.

However, there is a lot of other html,js,css content that we'd also like to have compressed.

With Glassfish 2.1 we switched on compression and all was well. Glassfish compressed all html, js, css, etc. and ignored content that was already compressed by these other filters.

With Glassfish 3.1.2.2 any stream that is already compressed by these other Servlet Filters comes out garbled. Other content not compressed by these filters comes out fine and is compressed.

I can only assume that Glassfish is not detecting that the stream is already gzipped and is gzipping it again.

Is there any way to modify this behaviour? Is this a bug?

Thanks.

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,

can you pls. attach the testcase for us, so we can reproduce the problem?

Thanks.

WBR,
Alexey.

arosso
Offline
Joined: 2010-02-19
Points: 0

I've attached a simple zip file with an exploded war. This includes a simple index.html and the tuckey urlrewritefilter.

Deploy this into Glassfish 3.1.2.2 (I believe the same problem exists in 3.1.2.1) with some context (e.g. /test). Then access the main page (/test/index.html). All is well if compression is off. Now switch on compression and try again (after clearing browser cache). Output is garbled.

Here is the domain.xml entry for our compression settings:

This is not an issue specific to the urlrewritefilter. I'm just including this since it's a open source component. We have 2 other web apps which also do the same kind of compression which also have the same issue.

This all worked fine in Glassfish 2.1.

Thanks.

oleksiys
Offline
Joined: 2006-01-25
Points: 0

Can you pls. include the domain.xml entry?

Thanks.

arosso
Offline
Joined: 2010-02-19
Points: 0

Seems to have gotten stripped out. Trying again:

<http ... compression="on" compressable-mime-type="text/html,text/xml,text/javascript,text/css">
oleksiys
Offline
Joined: 2006-01-25
Points: 0

Oh, you're right it's a bug, just because of a typo :(
Can I ask you to file an issue [1]?

I'm also attaching the patch for Glassfish 3.1.2.2, pls. copy this file into glassfish3/glassfish/modules folder.

Thanks.

WBR,
Alexey.

[1] http://java.net/jira/browse/GLASSFISH

Anonymous

Thank you. The patch does indeed work. I've filed an issue:
http://java.net/jira/browse/GLASSFISH-19354 Is this a fairly 'safe' fix? Or
should I wait for a more formal patch? Thanks again for the quick turn
around.

--

[Message sent by forum member 'arosso']

View Post: http://forums.java.net/node/892262

arosso
Offline
Joined: 2010-02-19
Points: 0

Thank you. The patch does indeed work.

I've filed an issue: http://java.net/jira/browse/GLASSFISH-19354

Is this a fairly 'safe' fix? Or should I wait for a more formal patch?

Thanks again for the quick turn around.

Anonymous

Hi, it's pretty safe patch, the only difference is "!" (not) operator added
before expression, which checked if "Content-Encoding" header is already
present in the response, so Glassfish compression doesn't have to be applied.
WBR, Alexey.

--

[Message sent by forum member 'oleksiys']

View Post: http://forums.java.net/node/892262

oleksiys
Offline
Joined: 2006-01-25
Points: 0

Hi,

it's pretty safe patch, the only difference is "!" (not) operator added before expression, which checked if "Content-Encoding" header is already present in the response, so Glassfish compression doesn't have to be applied.

WBR,
Alexey.