[jboss-jira] [JBoss JIRA] (WFLY-4196) HTTP protocol violation

[Stuart Douglas (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029456#comment-13029456 ] 

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)