tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan>
Subject Re: http 302 issue on tomcat 4.0.1
Date Tue, 04 Jun 2002 03:25:26 GMT
Yes, this is true.  Also, a request to /foo which becomes /foo/index.jsp 
would also screw up relative links.

I believe the following behavior would do what people want 99% of the 
time while still not screwing up the scenario you mentioned or the one I 
mentioned above (forgive the pythonic pseudocode):

if matchingWelcomeFile.equals("a/b.jsp"): //if the welcome file has a 
slash in it
  redirect( pathRequest + [forwardSlash if needed] + "a/" )
  if pathRequested.endWith('/'):
      redispatch // see below for meaning
      pathRequest += '/'
      redirect( pathRequest )

This only does redirects when necessary to preserve relative link 
meanings, and does not make so the redirected URL contains the 
welcome-file filename in any circumstance.  This is what people prob. 
want, since if people bookmark "/shoppingCart", they'll still have the 
right URL even if people switch from .jsp to .xtp or whatever.... 
 Incidentally, this is the behavior that Resin has--I checked.

I believe that this code shouldn't be in  It should 
be in the code that maps the request to a servlet.   I think this is 
clear from the spec ( SRV.9.10 ):  If no matching welcome file is found 
in the manner described, the container may handle the request in a 
manner it finds suitable. For some configurations this may mean invoking 
a default file servlet, or returning a directory listing. For other 
configurations it may return a 404 response.

So by redispatch, I mean 'pretend that the changed path is what was 
originally requested'.  This should be easy to do in the wrapper mapping 

Since I won't be forwarding ( since I won't be handling this in 
DefaultServlet ) your security constraint problems should be allayed.

And I think I can fix the 'mapping welcome files onto servlet' problem 
while I'm at it.



Remy Maucherat wrote:

>>Fixing this requires mucking with the core of Tomcat, which I find scary.
>>Do we have any regression tests I can use to see if my changes have
>>broken anything?  Or should I just commit the changes when they are
>>ready, and hope someone will notice any bugs before we release?
>>I'm asking because I would hate to be the cause of a totally messed up
>A forward is not used in that case because a security constraint may be
>applied on the target URI.
>Also, welcome pages such as "foo/index.html" are allowed, and using a
>forward would mess up the links from that welcome page (maybe that's normal,
>but it's not very clear to me).
>To unsubscribe, e-mail:   <>
>For additional commands, e-mail: <>

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

View raw message