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

[Nicolas Cazottes (JIRA)]

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

Nicolas Cazottes commented on WFLY-4196:
----------------------------------------

Hello,

I have done a few more search on this subject and you guessed right. 
Actually, the gzip filter uses an HttpServletResponseWrapper that overrides the method setContentLength with an implementation that does nothing.
This wrapper does not override setContentLengthLong as it has been written with servlet 2.5 compliance.

I upgraded the filter's building dependency javax.servlet-api version to 3.1 and overriden the setContentLengthLong method to do nothing. 
It works then successfully with wildfly and also all versions of Jboss on which my application runs :).

My conclusion is that, for my use case, wildfly breaks the compatibility of the servlet api previous to 3.1 : it requires the application to be rebuild with a constraint of 3.1 servlet api version.
I don't know if wildfly should be able to run pure servlet 2.5 web application for spec compliance and if this point is to be considered a bug or if 3.1 is mandatory for the application to be run.



> 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)