Content-Length Header is set allthough response is compressed by CompressionFilter

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Web-App serving static files by the Default-Tomcat8-Servlet and with 
Compression-Filter enabled (see example webapp webutilities.war attached)
2. GET request (with Accept-encoding:gzip) to any static file served by the 
Default-Tomcat8-Servlet big enough to be compressed by the compression filter. 
E.g. GET request to .../jquery-2.1.3.js in the example webapp
3. In the reponse a Content-Length header is set (containing the original size 
of the file served). This causes of course clients to keep the connection open 
after receiving the zipped data. In case of Tomcat8 the connection is kept open 
for 20s until it is aborted.

I'm using webutilities 0.0.7, windows 7, tomcat 8.0.20, java 1.7.0_72

reason?:
The Default-Tomcat8-Servlet seems to use the new Servlet-Api 3.1 function 
ServletResponse.setContentLengthLong to set the Content-Length. 
CompressedHttpServletResponseWrapper does not override this function yet.

Original issue reported on code.google.com by ole...@gmx.de on 25 Jun 2015 at 7:35

Attachments:

• webutilities.war

[GoogleCodeExporter]

Need to check and fix.

Original comment by rr.patil...@gmail.com on 27 Jun 2015 at 1:43

[GoogleCodeExporter]

Original comment by rr.patil...@gmail.com on 2 Aug 2015 at 7:15

• Added labels: Milestone-0.0.8

[GoogleCodeExporter]

https://github.com/rpatil26/webutilities/commit/6a59ecdb57a7ef0d49c96ea5782f4731
7e28bc1d

Original comment by rr.patil...@gmail.com on 4 Aug 2015 at 8:13

• Changed state: Fixed