The spec says that for each welcome file you must check 'whether a
resource in the WAR is mapped to that request URI. The web container
must send the request to the first resource in the WAR that matches. '
This is somewhat ambiguous--do they mean resource like getResource(...)
or do you mean a mapping in the deployment descriptor. Given the
example you mentioned, it seems they probably mean resource like
getResource(...).
If this is true, then bug 9016 is actually by design...
[PROPOSAL] We could do the following, which might be a good compromise
between the two possible interpretations:
If there is one welcome-file, then always redirect to it. If there is
no corresponding resource, then this could give us a 404 ( if it is a
JSP ) or work properly ( if it is a *.do ). Happily this does not
violate the spec, because the spec says that if no resource if found,
the container can do whatever it wants anyway.
If there is more than one welcome-file, then we do need to check for
corresponding resources. If none are found, we probably give a 404, right?
This is a little ugly since one wouldn't expect the behavior to change
when adding a welcome-file, but it might be the best solution.
Thoughts? I'm slightly leaning towards saying the behavior in bug 9016
is spec-mandated.
As for the speed issue, I would be happy to address it with caches or
something else ( I love optimizing ) when someone gave me very
conclusive proof that the mapping overhead is significant.
-Dan
Remy Maucherat wrote:
>>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
>>
>>
>
>This redirect may cause problems, because it will happen regardless of
>whether or not the path exist (or it makes sense to redirect).
>
>Example:
>You have index.jsp and index.html in the welcome files. No matter what you
>do,
>the request will always be redirected to Jasper, which will always return a
>404. Checking for the presence of the physical file won't work either
>(you could have a *.do mapping like Struts uses).
>
>Any idea to avoid that problem ?
>
>Also, the changes are going to make the mapping slower. I plan to refactor
>that
>operation (use an automaton and bytes instead of String manipulations) in
>the
>next major version of Tomcat, which should help tremendously, but until
>then ...
>
>
>
>> 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/ )
>>
>>
>
>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]>
