tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
Subject Re: http 302 issue on tomcat 4.0.1
Date Wed, 05 Jun 2002 01:09:10 GMT
> 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,

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.


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

View raw message