> It seems like there are only a few things we can do about this:
>
> 1. Call the servlet, buffer its output, and see if it is an error. If
> it is an error, try the next file in the welcome list. If not, use it.
> This relies on servlets honoring this convention. It also slows down
> throughp
>
>
>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 de
> 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
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 me
> 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,
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
els
> 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 pytho
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 pseu
> >
> > 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?
> >
There is in fact a regression test suite, in the "tester" subdirectory of
t
> 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
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
Hi Remy.
I filed a bug report about this a week ago at:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9559 ( which was
marked invalid )
Apparently this is a long-standing issue, as I found the following bug (
marked invalid ):
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=456
I hope
Hello,
When browsers request my url containing a filename, Tomcat does not
internally redirect this request, it sends a HTTP 302 redirect.
How can we configure and patch Tomcat to disable this feature ?
Thx for any help.
Here is what we get :
GET / HTTP/1.0
host: www.SiteName.com
HTTP/1.1 3
13 matches
Mail list logo