tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stone, Timothy" <tst...@cityofhbg.com>
Subject jsp:include behavior... help needed.
Date Fri, 24 Jan 2003 18:33:24 GMT
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:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message