You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by "remy.menetrieux" <re...@pixelpark.com> on 2002/06/03 17:27:25 UTC
http 302 issue on tomcat 4.0.1
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 302 Moved Temporarily
Content-Type: text/html
Date: Tue, 28 May 2002 10:34:13 GMT
Location: http://www.SiteName.com/index.htm
Server: Apache Tomcat/4.0.1 (HTTP/1.1 Connector)
Connection: close
<html><head><title>Apache Tomcat/4.0.1 - Error
report</title><STYLE><!--H1{font-family : sans-serif,Arial,Tahoma;color :
white;background-color : #0086b2;} BODY{font-family :
sans-serif,Arial,Tahoma;color : black;background-color : white;} B{color :
white;background-color : #0086b2;} HR{color : #0086b2;} --></STYLE>
</head><body><h1>Apache Tomcat/4.0.1 - HTTP Status 302 - Moved
Temporarily</h1><HR size="1" noshade><p><b>type</b> Status
report</p><p><b>message</b> <u>Moved
Temporarily</u></p><p><b>description</b> <u>The requested resource
(Moved Temporarily) has moved temporarily to a new location.</u></p><HR
size="1" noshade></body></html>
Re: http 302 issue on tomcat 4.0.1
Posted by Dan Sandberg <x...@cs.stanford.edu>.
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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: http 302 issue on tomcat 4.0.1
Posted by Remy Maucherat <re...@apache.org>.
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: http 302 issue on tomcat 4.0.1
Posted by Dan Sandberg <x...@cs.stanford.edu>.
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?
-Dan
Remy Maucherat wrote:
>>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 would hate to be the cause of a totally messed up
>>release...
>>
>>
>
>A forward is not used in that case because a security constraint may be
>applied on the target URI.
>Also, welcome pages such as "foo/index.html" are allowed, and using a
>forward would mess up the links from that welcome page (maybe that's normal,
>but it's not very clear to me).
>
>Remy
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: http 302 issue on tomcat 4.0.1
Posted by "Craig R. McClanahan" <cr...@apache.org>.
> >
> > 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
the jakarta-tomcat-4.0 repository. After you build Tomcat, build and
install the tester webapps like this:
cd tester
ant deploy
Then start or restart Tomcat and run:
$CATALINA_HOME/bin/tester.sh foo
to run the "foo" set of tests. If you leave off "foo", it will run all of
them. Too see what's available:
$CATALINA_HOME/bin/tester.sh -projecthelp
Each test outputs a success or failure message -- grep for FAIL in the
output is the easiest way to check for problems.
Besides passing the test suite, you should also ensure that the Watchdog
tests also pass (they are the basis for the tests that check for spec
compliance against the Servlet 2.3 and JSP 1.2 specs) from the
"jakarta-watchdog-4.0" CVS repository.
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: http 302 issue on tomcat 4.0.1
Posted by Remy Maucherat <re...@apache.org>.
> 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 would hate to be the cause of a totally messed up
> release...
A forward is not used in that case because a security constraint may be
applied on the target URI.
Also, welcome pages such as "foo/index.html" are allowed, and using a
forward would mess up the links from that welcome page (maybe that's normal,
but it's not very clear to me).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: http 302 issue on tomcat 4.0.1
Posted by Dan Sandberg <x...@cs.stanford.edu>.
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 would hate to be the cause of a totally messed up
release...
Thanks,
Dan
Dan Sandberg wrote:
> 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 to submit a patch for it within a week. I may also fix the
> following welcome-related bugs:
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9016
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8752
>
> -Dan
>
> remy.menetrieux wrote:
>
>> 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 302 Moved Temporarily
>> Content-Type: text/html
>> Date: Tue, 28 May 2002 10:34:13 GMT
>> Location: http://www.SiteName.com/index.htm
>> Server: Apache Tomcat/4.0.1 (HTTP/1.1 Connector)
>> Connection: close
>>
>> <html><head><title>Apache Tomcat/4.0.1 - Error
>> report</title><STYLE><!--H1{font-family :
>> sans-serif,Arial,Tahoma;color :
>> white;background-color : #0086b2;} BODY{font-family :
>> sans-serif,Arial,Tahoma;color : black;background-color : white;}
>> B{color :
>> white;background-color : #0086b2;} HR{color : #0086b2;} --></STYLE>
>> </head><body><h1>Apache Tomcat/4.0.1 - HTTP Status 302 - Moved
>> Temporarily</h1><HR size="1" noshade><p><b>type</b> Status
>> report</p><p><b>message</b> <u>Moved
>> Temporarily</u></p><p><b>description</b> <u>The requested resource
>> (Moved Temporarily) has moved temporarily to a new location.</u></p><HR
>> size="1" noshade></body></html>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: http 302 issue on tomcat 4.0.1
Posted by Dan Sandberg <x...@cs.stanford.edu>.
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 to submit a patch for it within a week. I may also fix the
following welcome-related bugs:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9016
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8752
-Dan
remy.menetrieux wrote:
> 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 302 Moved Temporarily
> Content-Type: text/html
> Date: Tue, 28 May 2002 10:34:13 GMT
> Location: http://www.SiteName.com/index.htm
> Server: Apache Tomcat/4.0.1 (HTTP/1.1 Connector)
> Connection: close
>
> <html><head><title>Apache Tomcat/4.0.1 - Error
> report</title><STYLE><!--H1{font-family : sans-serif,Arial,Tahoma;color :
> white;background-color : #0086b2;} BODY{font-family :
> sans-serif,Arial,Tahoma;color : black;background-color : white;}
> B{color :
> white;background-color : #0086b2;} HR{color : #0086b2;} --></STYLE>
> </head><body><h1>Apache Tomcat/4.0.1 - HTTP Status 302 - Moved
> Temporarily</h1><HR size="1" noshade><p><b>type</b> Status
> report</p><p><b>message</b> <u>Moved
> Temporarily</u></p><p><b>description</b> <u>The requested resource
> (Moved Temporarily) has moved temporarily to a new location.</u></p><HR
> size="1" noshade></body></html>
>
>
>
>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>