jsp:include behavior... help needed.

["Stone, Timothy" <ts...@cityofhbg.com>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: jsp:include behavior... help needed.

["Craig R. McClanahan" <cr...@apache.org>]

If you take a look at the standard Tomcat $CATALINA_HOME/conf/web.xml
file, you'll see that ".css" files are mapped to "text/css".  Try changing
this to "text/html" and see if that helps.

Another alternative would be to use the include directive (<%@ include %>)
instead of the include action (<jsp:include>), so that it happens at
compile time instead of runtime -- this only works if your stylesheets are
static, though.

Craig


On Fri, 24 Jan 2003, Stone, Timothy wrote:

> Date: Fri, 24 Jan 2003 13:33:24 -0500
> From: "Stone, Timothy" <ts...@cityofhbg.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: jsp:include behavior... help needed.
>
> 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:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>