[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=13029434#comment-13029434 ] 

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

Hi, I confirm after adding this configuration that the default gzip filter in undertow works correctly without any problem.
Neverless, my need is to handle it in the application and not globally in the server.

For the different ideas, as it works correctly in previous versions of Jboss (EAP 6, EAP 5 and EAP 4) with the same WAR, I think, you should perhaps look at how it is managed in these versions (I suppose in tomcat) to set a similar strategy.
I think for example, a strategy could be to detect that under a defined content size (for example 64kb), undertow bufferize and set the content-length after the filter processing. If more than 64kb content is detected, switch to chunked encoding which is justified.

To complete my case, my application serves small files like in the given sample war but also big text files of 25Mb which compress in a few Mb transparently through this gzip filter.

This problem seems not to be specific to gzip compression. Imagine a filter that does pre or post processing of files (js or css server side includes for example), the problem would be the same. From what I have seen with my application, for jquery.js file, if the browser does not have the correct Content-Length size, the file is not correctly interpreted.


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