Bulk closing issues resolved against old releases

I had the same issue with WF-CR1. Using WF build #933 (Feb 4, 2014 8:05:59 PM) GZipFilter can be enabled and works as expected.

I think this should already work properly in wildfly master.

can you try to reproduce this with nightly builds https://ci.jboss.org/hudson/job/WildFly-latest-master/ we just want to make sure this works before we release .Final

I think I know what may be causing this. Is there any chance that liferay is setting both:

Transfer-Encoding: chunked
Content-Length: x

headers?

It looks like Undertow does not handle this situation correctly, according to the RFC in this case the content-length should be ignored, which Undertow is not doing. I will fix upstream, which will hopefully resolve the issue.

So looking at the code here:

http://grepcode.com/file/repo1.maven.org/maven2/com.liferay.portal/portal-impl/6.0.6/com/liferay/portal/servlet/filters/gzip/GZipResponse.java#GZipResponse

One possible issue is that setContentLength(long) is not overridden, so if portlet uses this method compression will not work. This seems unlikely though.

Basically we need to figure out how the content length is being set. Undertow will automatically set a content length header if the output stream is closed without being flushed, and the response fits entirely in the buffer, however I can't see how that would be the cause.

Sounds like it has something to do with the content-length for compression being wrong.

How is compression handled? It is a custom filter in Liferay?

It seems that it only happens when a browser requests compression.
If it doesn't, it works. if it does, then the backend after receiving a request immediately closes the connection with such an exception:
18:02:41,484 ERROR [io.undertow.request] (default task-9) Blocking reques
t failed HttpServerExchange

: java.lang.RuntimeException:
io.undertow.server.TruncatedResponseException
at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(
HttpServletResponseImpl.java:532)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirst
Request(ServletInitialHandler.java:287)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchReq
uest(ServletInitialHandler.java:227)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(
ServletInitialHandler.java:73)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleReq
uest(ServletInitialHandler.java:146)
...

It happens only on liferay. it may be caused by some filter running on it.

I cannot confirm that, because i'm trying to run it on production and backend is not globally available.
But I can confirm that it works when proxied over ajp, but not http.
Every other app works over http.

So without reverse proxy it works ok?

I was wrong saying that it does not send status line.
The response is correct, but after headers there are many many blank lines before start of html code.
There is no important stacktrace there, to reproduce this bug, you should just deploy liferay behind a reverse proxy and try to load the main page.