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

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

I did some search in the source code and in debug mode and there is no call to the HttpServletResponse.setHeader or HttpServletResponse.addHeader methods for the Content-Length header.

Another point is that the server returns a value for the Content-Length of 3854 bytes where as the real (compressed size is smaller and is of 3760 bytes).
So I think that undertow determines the size of the Content-Length before the filter applies and should instead wait the end of the filter to set the value of the Content-Length header.

What do you mean by clearing the Content-Length header ? I do not see any API to remove an HTTP Header in HttpServletResponse.

For the test of the gzip subsystem configured in undertow, if I activate it via the command /subsystem=undertow/configuration=filter/gzip=gzipfilter/:add, fiddler does not detect any compression on the wire at all. Is it the correct way of activating it ?


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