tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: JSP in Static Resources
Date Mon, 15 Jul 2013 09:43:02 GMT
Alireza Fattahi wrote:
> Thanks for help!
> Let me summarize:
> There are two servlets as below:
> 1- Default servlet which process all static resources
> 2- jsp servlet which process the JSP file


> The mime types ( which are defined in localhost-config/web.xml) are only used bydefault

Yes, but you should remove the parenthesis.

> When I ask the jsp servlet to process the .css files, this servlet will always set the
MIME to text/html.

By default, yes, the JSP servlet sets the content-type to HTML.
This is a *default*, and it is chosen this way to save precious programmer keystrokes to 
state the content-type explicitly, for the majority of cases (because overwhelmingly, JSP

pages usually return HTML content).
So it belongs to the programmer to explicitly specify the content-type, it it does not 
match the default.  This is the case for *any non-HTML* content, whether it is CSS, 
Javascript, images or whatever.

> So this problem could be solved  if the servlet mapping has something like mime-type
as below:
> <servlet-mapping>
>     <servlet-name>jsp</servlet-name>
>     <url-pattern>*.css</url-pattern>
>    <mime-type>text/css</mime-type>
> </servlet-mapping>

Yes, but you should realise that this is "syntactic sugar" : it saves some keystrokes for

the programmer, at the cost of making the server more bloated.
Just like for standard HTML, each page should contain an indication of what it's content is.

> I should ask to put this in next servlet jsr !!
See Mark's answer.

> So, may be I try to write a servlet to set the content type.
> Do you know if tomcat has a build in filter or servlet for that.
> Some thing like: org.apache.catalina.filters.SetCharacterEncodingFilter which sets the
See Mark's answer.

Alireza, (hoping that this is your first name)

basically my own opinion is :
Your idea of incorporating Java code into the CSS pages, to achieve what you want, is 
clever, and it is technically possible.  But the fact that it is clever and technically 
possible does not mean that you should necessarily do it that way.  That way of doing it,

in my view, has a number of disadvantages which more than compensate for the cleverness :

it would not work under all versions of all servers, it does not allow caching of the CSS

files, it makes it more difficult to understand and maintain the pages of your website, 
and it makes things so that your CSS pages are not really pure CSS pages anymore. It also

makes it so that each time your server will serve a CSS page, it will have to run a few 
tens of thousands of additional CPU cycles, compared to having the CSS files as pure 
static documents. And it willhave to do this more often, because they are not static 
anymore and will not be cached by the browsers and/or server.
I would not do it that way, and I would try to apply the cleverness somewhere else.  You 
have the "real" JSP pages of your site, which /must/ already be "compiled" and "executed"

via the JSP process anyway.  One additional instruction in these pages is not going to 
make a big difference.  But making the CSS pages go from being static to being dynamic is

a big difference, with a series of side-effects now and in the future that are difficult 
to predict.

But it's your application and your choice.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message