Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
Message-ID: <009e01c20b87$e9eb07e0$6501a8c0@apache.org>
From: "Remy Maucherat" <remm@apache.org>
To: "Tomcat Developers List" <tomcat-dev@jakarta.apache.org>
References: <3CFB8ADD.50309@pixelpark.com> <3CFBBE71.9000100@cs.stanford.edu>
 <3CFBC0B9.2000401@cs.stanford.edu>
 <004a01c20b71$f8eff2c0$6501a8c0@apache.org>
 <3CFC3326.4030102@cs.stanford.edu>
Subject: Re: http 302 issue on tomcat 4.0.1
Date: Mon, 3 Jun 2002 22:23:07 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> 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:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>