> 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.
Ok, but this changes the bahavior of Tomcat, so this has the potential to break things. Also, the new spec clarifies it a bit, and requires to be able to do welcome files on non-existing paths, but which map to something (so getResource is not a good test). Since everything maps to the default servlet, I don't see how to implement this. > 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? I'd say no, because it could be a directory listing. > 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. I would like to fix it, but I don't know if it's possible. > 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. I did some OptimizeIt profiles, and the mapping is quite bad. Going with a byte-based mapping would help. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
