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

Stuart Douglas commented on WFLY-4196:
--------------------------------------

The call that is used to set the length is response.setContentLengthLong(contentLength)
With regard to clearing the header it should be possible to call setHeader("Content-Length", null); 

In order to activate the built in handler you also need to attach it to a host (note that the predicate part is used to determine which requests have the filter applied):

/subsystem=undertow/server=default-server/host=default-host/filter-ref=gzipfilter:add(predicate="path-suffix[.css] or path-suffix[.js]")

I will have a bit more of a think about how to best handle situations like this. In particular there are a few issues:

- If the default servlet does not set the content-length header then chunked encoding will be used, which is less efficient, and means that a browser can't display a progress bar when downloading files. 

- It is not really possible for compression filters to set a content length unless they are prepared to buffer the whole resource, as the content length can't be determined until the whole response has been compressed. If the filter is buffering the whole resource then it should just set a content length

- We can't wait till the filter is done to set the content length, this is done by the default servlet that knows how big the file it is serving is. On possibility would be to just not set the content length header if it detects that the output stream has been wrapped. Another possibility would be to automatically clear the content-length if a transfer or content encoding header is set, although both of these could potentially cause problems. 

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