List,
We have recently been alpha testing an application that must run over a wireless
network still running at Flintstone speeds (at best 19.2 but closer to 4800~9600!) As
faster wireless is out of the question (management, funding and other obstacles are
factors), we have implemented the CompressionFilter as found in Tomcat 4.1.1x.
This CompressionFilter cut the load time of a 300+K document from 6:15 (minutes) to
1:30 (minutes)! (We are considering a rewrite of the compression filter as well to
better handle the response in bulk, possibly cutting some more time from the
response.) But in implementing the filter we noted some irregularity in how the
response was being interpreted by the client (Mozilla *and* MSIE 5.x+).
Both browsers "Accept-Content: gzip, deflate" so on the surface the compression filter
should work. However, our first deployments caused the browser to present the file
download dialog for a CSS (text/css) document.
Turning debugging features on in the CompressionFilter showed the following:
...
doFilter gets called with compression
setContentType to text/html;charset=ISO-8859-1
setContentType to text/html;charset=ISO-8859-1
setContentType to text/css
...
Examining the document, file.jsp, showed what we knew... the CSS was sourced:
<jsp:include page="/common/css/common.css"/>
We were able to fix this problem, rather unelegantly, by adding the following
scriptlet in /common/css/common.css immediately following the <jsp:include...>:
<%
response.setContentType( "text/html" );
%>
This corrected the problem as can be seen in the new logging output:
...
doFilter gets called with compression
setContentType to text/html;charset=ISO-8859-1
setContentType to text/html;charset=ISO-8859-1
setContentType to text/css
setContentType to text/html
...
We have poured over the code for the CompressionFilter, it is doing what is suppose to
do... but we can't run down where the content is being set as we are not explicitly
setting it; or we don't fully understand the behavior of the server when sourcing
documents.
Any suggestions for a more elegant solution would be welcome, even some background
information on how JSPs receive the Content-Type response headers.
Thank in Advance!
Tim
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
