tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurice Yarrow <>
Subject Re: hacking the tomcat DefaultServlet
Date Wed, 19 Oct 2005 01:21:09 GMT

I *LIKE* this idea.  Yes!
And it simply does an endrun around my machinations here.

But, actually, I have a question.

For this to work for me, it would have to be the case that
this filter is in front of the tomcat DefaultServlet.  Which
means that <filter> and <filter-mapping> elements need
to go in front of the <servlet> element for the DefaultServlet
in the conf/web.xml.   Is that the case?  Am I
misunderstanding something?

After all, this cannot be in my web app context, because,
as I found, even when I place a (only slightly) hacked
version of DefaultServlet in my context and call it, say,
ImgServlet, though it will cause IE to correctly cache under
http, IE will not cache downloaded images properly under https.
Don't know why.   So what I didn't mention in my first letter
is that I also tried, in own ImgServlet (not a hacked DefaultServlet)
to simply do as you suggested inside of the filter, which is to point
the getRequestDispatcher to the new path, which is in its own context
which has a context.xml -> allowLinking=true, override=true.  This
will see and serve the images correctly.  But, under https, IE will
still will display but not cache them for re-use.  These images
keep getting reloaded under https.  And this is true
even though the servlet has. as I said, a bunch of appropriate
response.setHeader(attribName, attrib) calls for setting the
properties necessary for caching and a 
getLastModified(HttpServletResponse resp) override method.

It all works just fine under http, so it is obviously something
peculiar that I just don't understand that is requred but missing,
I assume.

So, my question is: can I request that a filter be applied to all
static page requests that are going to DefaultServlet?  Or is this
done with a Valve?

If a filter, do I need to put <filter> and <filter-mapping> elements
in front of the <servlet> element in tomcat/conf/web.xml ?
Note that there is no mention of such elements in the tomcat
documentation, though it does appear to be required by the J2EE spec.


Tim Funk wrote:
> Use a servlet filter to rewrite the request and let the DefaultServelt 
> stay untouched. Then you get easily maintainable code and its not tomcat 
> specific. For example:
> doFilter(request, response, filterChain) {
>   if (magicalCanRewrite(request)) {
>     String newPath = 
> magicMethodTOGetNewPathFromSessionOrWhereever(request);
>     RequestDispatcher rd = request.getRequestDispatcher(request, response);
>     rd.forward(request, response);
>   } else {
>     filterChain.doFilter(request, response);
>   }
> }
> -Tim
> Maurice Yarrow wrote:
>> Hello tomcat users
>> I have hesitated a while before sending up this question,
>> for the presumably obvious reason that hacking the tomcat
>> DefaultServlet is an act of questionable judgement.  But
>> there are some good reasons why I experimented with this.
>> In my attempt to get more control over visibility of static
>> resources on my tomcat 5.0.28, I decided first to write my
>> own static page downloader servlet which was intended only
>> for images and applets.  By first defining such a
>> servlet-mapping as
>>     <servlet-mapping>
>>         <servlet-name>ImgServlet</servlet-name>
>>         <url-pattern>/Img/*</url-pattern>
>>     </servlet-mapping>
>> in my app web.xml, I can thereupon
>>     request.getPathInfo();
>> and obtain the trailing portion of an invoking URL
>> such as
>> Then request.getPathInfo() returns
>>     /a/b/c.jpg
>> Now, of course, the ImgServlet checks the session obj
>> for authentication purposes, and, having accepted it as
>> having a valid session, it then checks and modifies the
>> /a/b/c.jpg to appropriately point to the actual disk
>> resource.
>> It is therefore impossible for a client without a valid
>> session to simply look at something like
>> because the actual resource isn't available through anything
>> like this.
>> Of course, I wrote a download server that includes all the
>> right method response.setHeader(attribName, attrib) and a
>> getLastModified(HttpServletResponse resp) override 
>> stuff to mimic what the tomcat DefaultServlet does, and though
>> my static page server allows browsers to get the file efficiently
>> (via BufferedOutputStream(response.getOutputStream,...) and
>> to cache the file fine under http, this would not provide
>> files that cached under https and Internet Explorer  (it did
>> work fine for mozilla!).
>> So then I tried the tomcat DefaultServlet, which I compiled
>> separately into my own webAppName app and modified to
>> accommocate the above capabilities.   But this did not cache
>> images under https/IE either.  Now, mind you, the tomcat
>> DefaultServlet does cache fine natively (i.e., within tomcat)
>> for both http and https and IE.
>> Now, of course, I could add the behaviour I want into the
>> actual .../org/apache/catalina/servlets/
>> in the tomcat source tree, and then replace the resultant
>> class files into the tomcat-5.0.28/server/lib/servlets-default.jar.
>> But for the reason that I don't really want to tinker too much
>> which this most basic core tomcat capability for security
>> reasons, I would rather resolve this in my web app.
>> So, actually, my simple question, really, is:
>> Does anyone who has done this kind of thing have any experiences
>> that they would care to share?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message