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" <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: Tomcat Users List <[EMAIL PROTECTED]> > 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: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
