[PATCH] forward welcome files
My last submission of this patch was heinously wrapped, and buried in a lot of
discussion.
This patch will:
- check for the presence of a 'forwardWelcomeFiles' init param. if not present, it's
false.
- if 'forwardWelcomeFiles' is true, a request with a trailing slash that resolves to a
welcome
file will return the welcome file. if false, it will send a redirect to the welcome
file.
Matt
--- DefaultServlet.java.orig2003-01-07 08:41:16.0 -0700
+++ DefaultServlet.java 2003-01-07 08:42:33.0 -0700
@@ -169,6 +169,10 @@
*/
protected String welcomes[] = new String[0];
+/**
+ * Should we redirect or forward for welcome files?
+ */
+protected boolean forwardWelcomeFiles = false;
/**
* MD5 message digest provider.
@@ -294,6 +298,13 @@
} catch (Throwable t) {
;
}
+try {
+value = getServletConfig().getInitParameter(forwardWelcomeFiles);
+if (value != null)
+forwardWelcomeFiles = (new Boolean(value)).booleanValue();
+} catch (Throwable t) {
+;
+}
// Sanity check on the specified buffer sizes
if (input 256)
@@ -957,11 +968,16 @@
if (welcomeFileInfo != null) {
String redirectPath = welcomeFileInfo.path;
String contextPath = request.getContextPath();
-if ((contextPath != null) (!contextPath.equals(/))) {
+if ((contextPath != null) (!contextPath.equals(/))
+(!forwardWelcomeFiles)) {
redirectPath = contextPath + redirectPath;
}
redirectPath = appendParameters(request, redirectPath);
-response.sendRedirect(redirectPath);
+if (forwardWelcomeFiles) {
+ request.getRequestDispatcher(redirectPath).forward(request,
+response);
+}
+else {
+ response.sendRedirect(redirectPath);
+}
return;
}
--- web.xml.orig2003-01-07 08:58:09.0 -0700
+++ web.xml 2003-01-07 08:50:13.0 -0700
@@ -39,6 +39,9 @@
!-- readonlyIs this context read only, so HTTP --
!-- commands like PUT and DELETE are --
!-- rejected? [true] --
+ !-- --
+ !-- forwardWelcomeFiles Should welcome files be forwarded instead --
+ !-- of being redirected? [false] --
servlet
servlet-namedefault/servlet-name
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
On Tue, 2003-01-07 at 04:40, Remy Maucherat wrote:
I'll -1 this patch unless the new behavior is made optional (and default
to the current behavior).
Remy
Okay, it's now an init param which defaults to false. Following are
DefaultServlet.java and web.xml patches.
--- DefaultServlet.java.orig2003-01-07 08:41:16.0 -0700
+++ DefaultServlet.java 2003-01-07 08:42:33.0 -0700
@@ -169,6 +169,10 @@
*/
protected String welcomes[] = new String[0];
+/**
+ * Should we redirect or forward for welcome files?
+ */
+protected boolean forwardWelcomeFiles = false;
/**
* MD5 message digest provider.
@@ -294,6 +298,13 @@
} catch (Throwable t) {
;
}
+try {
+value =
getServletConfig().getInitParameter(forwardWelcomeFiles);
+if (value != null)
+forwardWelcomeFiles = (new
Boolean(value)).booleanValue();
+} catch (Throwable t) {
+;
+}
// Sanity check on the specified buffer sizes
if (input 256)
@@ -957,11 +968,16 @@
if (welcomeFileInfo != null) {
String redirectPath = welcomeFileInfo.path;
String contextPath = request.getContextPath();
-if ((contextPath != null)
(!contextPath.equals(/))) {
+if ((contextPath != null) (!contextPath.equals(/))
(!forwardWelcomeFiles)) {
redirectPath = contextPath + redirectPath;
}
redirectPath = appendParameters(request, redirectPath);
-response.sendRedirect(redirectPath);
+if (forwardWelcomeFiles) {
+
request.getRequestDispatcher(redirectPath).forward(request, response);
+}
+else {
+ response.sendRedirect(redirectPath);
+}
return;
}
--- web.xml.orig2003-01-07 08:58:09.0 -0700
+++ web.xml 2003-01-07 08:50:13.0 -0700
@@ -39,6 +39,9 @@
!-- readonlyIs this context read only, so
HTTP --
!-- commands like PUT and DELETE
are --
!-- rejected?
[true] --
+
!-- --
+ !-- forwardWelcomeFiles Should welcome files be forwarded
instead --
+ !-- of being redirected?
[false] --
servlet
servlet-namedefault/servlet-name
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
On Tue, 2003-01-07 at 04:39, Remy Maucherat wrote: Matt Parker wrote: If you want to mirror what Apache HTTPD does: No slash present -- append slash (only!) and redirect Slash present -- internally forward to welcome-file page Well, here's the rub: - The new servlet spec clearly states that either /foo or /foo/ should return a welcome-file (if specified) Well, this is broken behavior. If no slash, then a redirect will be sent back to the client, otherwise, relative paths are not resolved correctly, with no way for the app writer to anticipate it. That's true. Although I think it would still satisfy the spec to redirect /foo to /foo/index.html, but would a redirect from /foo to /foo/, and then forward to /foo/index.html still satisfy it? Maybe I'm being too pedantic. The actual text reads: A request URI of /foo or /foo/ will be returned as /foo/index.html What do y'all think? I vote +1 :) I'll vote the opposite ;-) People are used to the bahavior in 4.1. In 5.0, I plan to add the option for internal forwards in the new mapper I'll write. Note that internal forwards were used in early 4.0 releases, but went away as it got reported as a security issue (the security checks apply to the original URI, not the served welcome file). Remy I hear ya. Didn't mean to be cute. Could the security check be applied after the welcome file was resolved? Or is that going to be done in your mapper? Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
On Mon, 2003-01-06 at 12:14, Hans Bergsten wrote: Matt Parker wrote: I'd like to suggest that catalina perform a forward, rather than a redirect, for requests that end with '/'. With a redirect, special configuration is necessary for proxy servers to work correctly. Also, a forward doesn't require an additional round trip to the client--a redirect must get back to the client and the client then issues a new request. I've tested this under Linux. Thanks! You mean requests that do _not_ end with '/', right? Unfortunatly, you must do a redirect in this case so that the browser can resolve relative paths in the page correctly. If you use a forward, it can't do so correctly. Hans No, I mean requests that _do_ end with a trailing slash, but that should be resolved to one of the files specified in the web application's welcome-file-list. This is similar to Apache's DirectoryIndex directive. Maybe the following Apache documentation snippet can explain it more clearly than I can: The DirectoryIndex directive sets the list of resources to look for, when the client requests an index of the directory by specifying a / at the end of the a directory name. For Apache, this is index.html by default. When Apache receives a trailing slash (e.g. /foo/bar/), it resolves index.html and returns it. Note that it does _not_ send a redirect to index.html. The redirect occurs only when there is no trailing slash at the end of a directory request (e.g. /foo/bar is redirected to /foo/bar/, which is then resolved to index.html) So tomcat's behavior is actually going against what Apache does. Hope I'm explaining it correctly. Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
On Mon, 2003-01-06 at 12:57, Costin Manolache wrote: The problem is that once again the servlet spec defines a behavior that is different from the common practices on web servers. I don't see that this particular behavior is actually specified, unless I'm looking in the wrong place. I think it leaves it open for the default servlet to interpret. The welcome-file-list can include more than index.html - you may have foo/index.html, etc ( i.e. things in other dirs ). That means #anchors would break if we don't do redirect. This argument would apply equally to Apache's current implementation. You can specify multiple index files with the DirectoryIndex directive. So since Apache doesn't redirect, this must not be the case. A second reason for doing redirects: a redirect will let the web server handle the file serving ( if the index.html is a static file - or some resource that apache can handle ). Then wouldn't that be specified in the web server's config? Also, redirecting the client to make yet another request couldn't possibly be faster than simply serving the static file. A third reason: it's safer :-) ?? how is it safer? Costin I don't mean to be argumentative, but I really think that it's The Right Way to do it. However I'll defer to the Tomcat team (I guess I don't have a choice :) Cheers, Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
On Mon, 2003-01-06 at 14:43, Hans Bergsten wrote: Okay, that's different. Maybe I misread your patch, but to me it looked as if you changed the behavior when there's no trailing slash. Actually my patch is forwarding under both circumstances, but according to SRV.9.10 of Servlet 2.4, this is actually correct (phew! :) Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Unable to compile class for JSP
you should post this to the tomcat-users list. this list is for issues related to development on the tomcat product. On Mon, 2003-01-06 at 16:48, Gary Pollreis wrote: I have just installed Tomcat 4.1.18 under Windows 2000 (using Java JDK 1.4.0). When I try to run the examples I get org.apache.jasper.JasperException: Unable to compile class for JSP . I have validated that my JAVA_HOME and CATALINA_HOME environment variables are correct. Any/all help would be appreciated. Thanks in advance. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Unable to compile class for JSP
Happy New Year :) On Mon, 2003-01-06 at 17:00, Gary Pollreis wrote: will do - thanks for the heads up. -Original Message- From: Matt Parker [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 5:57 PM To: Tomcat Developers List Subject: Re: Unable to compile class for JSP you should post this to the tomcat-users list. this list is for issues related to development on the tomcat product. On Mon, 2003-01-06 at 16:48, Gary Pollreis wrote: I have just installed Tomcat 4.1.18 under Windows 2000 (using Java JDK 1.4.0). When I try to run the examples I get org.apache.jasper.JasperException: Unable to compile class for JSP . I have validated that my JAVA_HOME and CATALINA_HOME environment variables are correct. Any/all help would be appreciated. Thanks in advance. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
On Mon, 2003-01-06 at 17:03, Tim Funk wrote: If a trailing / is not present, then performing a RequestDispatcher.forward will break all relative references (for the web browser) -Tim It doesn't forward until after it appends the trailing slash, so I think it's okay on that front. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
On Mon, 2003-01-06 at 15:28, Costin Manolache wrote:
Matt Parker wrote:
On Mon, 2003-01-06 at 14:43, Hans Bergsten wrote:
Okay, that's different. Maybe I misread your patch, but to me it looked
as if you changed the behavior when there's no trailing slash.
Actually my patch is forwarding under both circumstances, but according
to SRV.9.10 of Servlet 2.4, this is actually correct (phew! :)
Forwarding if there is no ending / doesn't seem right. I'm very sure
anchors will be broken.
The code to append a trailing / before it does anything else (assuming
it's a directory) is already present in the default servlet--my patch
forwards after this happens. Maybe I should have included more context
within the patch to make this clearer--sorry, I can see why this would
be so controversial without that key point. Otherwise it would
definitely break. The patch occurs after the line:
if (resourceInfo.collection) {
...
}
which means that it has already ruled that the request is a directory.
It may be a good idea to include a modified patch that makes this optional -
but IMO redirect should remain the default. But please verify that anchors
work, including cases where the welcome file is in another directory.
Verified the following:
http://foo/bar#anchor
http://foo/bar/#anchor
with a welcome-file of:
test/test.jsp
and was correctly forwarded to:
http://foo/bar/test/test.jsp#anchor
Matt
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
Verified the following: http://foo/bar#anchor http://foo/bar/#anchor with a welcome-file of: test/test.jsp and was correctly forwarded to: http://foo/bar/test/test.jsp#anchor okay, I was a little premature (no jokes please). if the welcome file itself has a relative link off of it, then it breaks. so that a href='foo.jsp' on test.jsp will try to go to http://foo/bar/foo.jsp rather than http://foo/bar/test/foo.jsp i'll see if i can fix that. sorry... Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
On Mon, 2003-01-06 at 17:11, Matt Parker wrote: On Mon, 2003-01-06 at 17:03, Tim Funk wrote: If a trailing / is not present, then performing a RequestDispatcher.forward will break all relative references (for the web browser) -Tim It doesn't forward until after it appends the trailing slash, so I think it's okay on that front. No, you're right. It's broken. Crud. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] forward instead of redirect for welcome files
If you want to mirror what Apache HTTPD does: No slash present -- append slash (only!) and redirect Slash present -- internally forward to welcome-file page Well, here's the rub: - The new servlet spec clearly states that either /foo or /foo/ should return a welcome-file (if specified) - Apache also has the problem with a relative link on a welcome file which has a directory specified in it However, I think that the patch benefits still outweigh its drawbacks: - it satisfies the new servlet spec - it circumvents the need for special processing and configuration when placed behind a proxy server (a farely common production practice). - it inherits a problem, but the problem is probably rare in practice, and will already have been avoided by Apache users since it's the same. i.e. i've never had a burning need to specify a welcome file or directory index that has a subdirectory in it _and_ has a relative link, so i can only guess that others either don't or already know to avoid it. What do y'all think? I vote +1 :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] forward instead of redirect for welcome files
Here's the new version of the patch. the code to redirect if there is no
trailing slash remains untouched, but it now forwards if there is a
trailing slash. i've included more context to avoid potential confusion:
--- DefaultServlet.java 2003-01-03 16:20:23.0 -0700
+++ DefaultServlet.java.new 2003-01-06 18:27:25.0 -0700
@@ -939,46 +939,42 @@
// If the resource is a collection (aka a directory), we check
// the welcome files list.
if (resourceInfo.collection) {
if (!request.getRequestURI().endsWith(/)) {
String redirectPath = path;
String contextPath = request.getContextPath();
if ((contextPath != null)
(!contextPath.equals(/))) {
redirectPath = contextPath + redirectPath;
}
if (!(redirectPath.endsWith(/)))
redirectPath = redirectPath + /;
redirectPath = appendParameters(request, redirectPath);
response.sendRedirect(redirectPath);
return;
}
ResourceInfo welcomeFileInfo = checkWelcomeFiles(path,
resources);
if (welcomeFileInfo != null) {
String redirectPath = welcomeFileInfo.path;
-String contextPath = request.getContextPath();
-if ((contextPath != null)
(!contextPath.equals(/))) {
-redirectPath = contextPath + redirectPath;
-}
redirectPath = appendParameters(request, redirectPath);
-response.sendRedirect(redirectPath);
+
request.getRequestDispatcher(redirectPath).forward(request, response);
return;
}
} else {
// Checking If headers
boolean included =
(request.getAttribute(Globals.CONTEXT_PATH_ATTR) !=
null);
if (!included
!checkIfHeaders(request, response, resourceInfo)) {
return;
}
}
// Find content type.
String contentType =
getServletContext().getMimeType(resourceInfo.path);
Vector ranges = null;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] forward instead of redirect for welcome files
On Mon, 2003-01-06 at 18:31, Tim Moore wrote: Unless I'm missing something, if you don't redirect from /foo to /foo/, then you'll have broken relative links even if the welcome file is not in a subdirectory. This would probably be a pretty common problem. For example, if your welcome file has a href=bar.html then resolving that relative to /foo would give you /bar.html while resolving it relative to /foo/ would give you /foo/bar.html. That means that relative links will either work or not work, depending just on whether the trailing slash is there. you're absolutely right (no pun intended :) I was spacing out--the redirect is necessary when there's no trailing slash, but forward is okay when there is a trailing slash. I posted a new version of the patch that forwards only when there's a trailing slash... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] forward instead of redirect for welcome files
I'd like to suggest that catalina perform a forward, rather than a
redirect, for requests that end with '/'. With a redirect, special
configuration is necessary for proxy servers to work correctly. Also, a
forward doesn't require an additional round trip to the client--a
redirect must get back to the client and the client then issues a new
request. I've tested this under Linux. Thanks!
Matt
--- DefaultServlet.java 2003-01-03 16:20:23.0 -0700
+++ DefaultServlet.java.new 2003-01-03 16:20:18.0 -0700
@@ -942,26 +942,18 @@
if (!request.getRequestURI().endsWith(/)) {
String redirectPath = path;
-String contextPath = request.getContextPath();
-if ((contextPath != null) (!contextPath.equals(/))) {
-redirectPath = contextPath + redirectPath;
-}
if (!(redirectPath.endsWith(/)))
redirectPath = redirectPath + /;
redirectPath = appendParameters(request, redirectPath);
-response.sendRedirect(redirectPath);
+request.getRequestDispatcher(redirectPath).forward(request, response);
return;
}
ResourceInfo welcomeFileInfo = checkWelcomeFiles(path, resources);
if (welcomeFileInfo != null) {
String redirectPath = welcomeFileInfo.path;
-String contextPath = request.getContextPath();
-if ((contextPath != null) (!contextPath.equals(/))) {
-redirectPath = contextPath + redirectPath;
-}
redirectPath = appendParameters(request, redirectPath);
-response.sendRedirect(redirectPath);
+request.getRequestDispatcher(redirectPath).forward(request, response);
return;
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
On Fri, 2003-01-03 at 17:14, Jon Scott Stevens wrote: on 2003/1/3 4:03 PM, Matt Parker [EMAIL PROTECTED] wrote: I'd like to suggest that catalina perform a forward, rather than a redirect, for requests that end with '/'. With a redirect, special configuration is necessary for proxy servers to work correctly. Also, a forward doesn't require an additional round trip to the client--a redirect must get back to the client and the client then issues a new request. I've tested this under Linux. Thanks! Matt That goes against the behavior of most HTTP servers, including Apache HTTPd. -jon It appears that Apache returns 301 only when there isn't a trailing slash. When there is a trailing slash, it returns a 200. Matt -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
