tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Funk <funk...@joedog.org>
Subject Re: hacking the tomcat DefaultServlet
Date Tue, 18 Oct 2005 10:54:56 GMT
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
> 
>     http://www.mySite.com/webAppName/Img/a/b/c.jpg
> 
> 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
> 
>     http://www.mySite.com/images/a/b/c.jpg
> 
> because the actual resource isn't available through anything
> like this.
> 
> Of course, I wrote a download server that includes all the
> right response.setHeader(attribName, attrib) and a
> getLastModified(HttpServletResponse resp) override method
> 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/DefaultServlet.java
> 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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message