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

[ https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin.... ] 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. -- This message was sent by Atlassian JIRA (v6.3.11#6341)