[
https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin....
]
Stuart Douglas commented on WFLY-4196:
--------------------------------------
So the only spec compliant way of implementing this is to wrap the HttpServletResponse
object in the filter, and then intercept and discard all calls to setContentLength and
setContentLengthLong (plus the general setHeader methods for content length).
Is it possible that your filter already does this, but does only does it for
setContentLength and not setContentLengthLong ? This method was added in Servlet 3.1 and
is used by the default servlet, so this would explain why you filter works in older
versions.
HTTP protocol violation
-----------------------
Key: WFLY-4196
URL:
https://issues.jboss.org/browse/WFLY-4196
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.1.0.Final, 8.2.0.Final
Reporter: Nicolas Cazottes
Assignee: Stuart Douglas
Priority: Blocker
Attachments: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war,
fiddler_protocol_violation.jpg
If you deploy the given war in wildfly and open this url
http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run
it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header
value.
Actually, If the content is some js or css, the browser does not correctly reads it and
the web page is corrupted.
The explanation is that the web application uses a filter to compress the content in gzip
format.
For information, this application works correctly with jboss as 7 or before (that embed
tomcat). I discovered the problem while trying to upgrade my application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)