[JERSEY-1228] Invalid Etag value with content encoded with GZIPContentEncodingFilter Created: 19/Jun/12  Updated: 22/Jun/12  Resolved: 22/Jun/12

Status: Resolved
Project: jersey
Component/s: containers
Affects Version/s: 1.9.1, 1.12
Fix Version/s: 1.13

Type: Bug Priority: Major
Reporter: doud Assignee: Martin Matula
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File GZIPContentEncodingFilter.java    
Issue Links:
Duplicate
is duplicated by JERSEY-1231 GZipContentEncodingFilter should incl... Resolved
Tags: entitytag, gzip

 Description   

Hi,
When zipping content with the GZIPContentEncodingFilter, any existing Etag value will not be modified. This is invalid because gzipping modifies content, and so Etag has to be modified (at least Strong Etags, but i'm not sure of this). Some cache proxies might provide gzipped content to clients that do not handle gzip.

This issue is still opened on the mod_deflate filter of Apache server (see https://issues.apache.org/bugzilla/show_bug.cgi?id=39727 ) since 6 years now.

One solution often proposed on the web is to add a suffix"-gzip" to the Etag header and the value "Accept-Encoding" to the vary header. But that's not sufficient, entity tag within request headers (usually "If-None-Match") should be processed too.
In attachment, i provide a patch (with updated javadoc) that at least match my needs (i use strong etags, so i tested with them).

Maybe should it be a specialized GZIPWithETagContentEncodingFilter as it does not solve same problem using the LastModified header. A single GZIPContentEncodingFilter dealing with all these "Cache-Control" issues may be too complex.
Edouard Chevalier



 Comments   
Comment by doud [ 19/Jun/12 ]

patch had a bug. It was adding the header "content-encoding = gzip" to responses with no entity.
Corrected in attached file

Comment by Martin Matula [ 22/Jun/12 ]

It's in.
https://github.com/jersey/jersey-1.x/commit/4ef18faf5e86289a49a8aa816e2625edc31b5f64

Thanks for the patch!





[GLASSFISH-19354] HTTP Double Gzip Compression Created: 17/Nov/12  Updated: 12/Mar/13  Resolved: 12/Mar/13

Status: Resolved
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: 3.1.2, 3.1.2.2
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: arosso Assignee: oleksiys
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Amazon Linux 2012 09


Attachments: Zip Archive doublecompression-test.zip    
Tags: grizzly, gzip, http

 Description   

See: http://www.java.net/forum/topic/glassfish/glassfish/glassfish-double-compression for discussion.

The Grizzly http listener does not detect that a response is already Gzipped and gzips it again causing the output to be garbled. This did not use to happen in Glassfish 2.1.x but seems to happen in 3.1.x.

To reproduce deploy the attached web app directory into Glassfish 3.1.2.2 and access index.html page. Now switch on compression and the output will be garbled.

domain.xml compression settings are:

<http ... compression="on" compressable-mime-type="text/html,text/xml,text/javascript,text/css">



 Comments   
Comment by oleksiys [ 19/Nov/12 ]

Related to Grizzly issue
http://java.net/jira/browse/GRIZZLY-1367

Comment by oleksiys [ 12/Mar/13 ]

fixed in GF 4





Generated at Wed Jul 29 16:17:03 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.