Here's the new and improved pseudocode. Anyone see any special cases
that I've missed?
if matchingWelcomeFile.contains("/"):
# psycopathic case no one cares about ( ie. welcome file is a/b.jsp )
redirect, old style //we show the filename here, but if we didn't we'd
break relative paths
else:
if path.endsWith("/"):
# happy, smiley family case
redispatch, using welcome-file full path (ie. /foo/index.jsp ) for
security checking
else:
if adding slash causes a servlet mapping match:
# we handle the stupid case of having two servlet mappings
# ( /foo and /foo/ ) in web.xml.
redirect, old style //we show the filename here, but if we didn't
we'd call the wrong servlet
else:
redirect, adding "/" ( ie. redirect /foo to /foo/ )
-Dan
Remy Maucherat wrote:
>>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/" )
>>else:
>> if pathRequested.endWith('/'):
>> redispatch // see below for meaning
>> else:
>> 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 DefaultServlet.java. 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
>>ocde.
>>
>>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.
>>
>>Comments?
>>
>>
>
>We can try it, but it will still cause problems with nested welcome files
>and relative paths.
>
>If you can implement it well, that would be cool.
>
>Remy
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
