Tim
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.
Maurice
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
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 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/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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
