Has anyone come across this problem ? Thanks.
This is a problem of filter, not ours. Default deflate compressor in Tomcat set the length right.
Sergey, Thanks for quick response.
Once I get rid of GZipFilter from web.xml, then I do not see this problem. But this may not be acceptable solution for us.
So I did debug the GZipCompression filter code, and found that GZipFilter is not changing the content-length header at all. So i am not really sure, who is setting the header value.
Is A4J, serving any of the resources in compressed format ?
Is there any recommended way for applying GZipCompression on JSF pages served using Jboss ?
Jboss AS bundled with a Apache Tomcat, where is compression built-in at the Connector level. See http://tomcat.apache.org/tomcat-6.0-doc/config/http.html , compression attribute description.
For a Jboss 4.2.1, edit $JBOSS_HOME/server/default/deploy/jboss-web.deployer/server.xml
Content-Length response header is setted by RichFaces resource framework. It value is important for a properly resource caching ( most browsers don't cache objects for unknown length ).
Thanks for response. I will look into those resources.
But I just wanted to bring up one more thing. On my page, I have modalPanel. So resources related to that are downloaded from these server as well. But I their case, content-length header is set correctly. So I am confused about, what so special about prototype.js resource.
Different values for a content length provided by filter, framework itself set real value for a resources with known size.
Wich implementation of a GZipFilter is used ?