RE: [PATCH] forward instead of redirect for welcome files

[travis]

I would like to revisit this thread:

http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg38851.html

This should be a required feature.  The current functionality is a BIG flaw in my eyes 
and obviously many other peoples for many reasons including:

- it is not the standard way that apache behaves (nor any other server on the planet, 
i mean even look at the jakarta site or any non tomcat site for that matter)
- gives a HUGE disadvantage to sites using tomcat for search crawlers and search 
engine rankings (this alone makes me want to try a different app server and if i 
didn't have the knowledge to change the DefaultServlet myself, I would definitely stop 
using tomcat because of this).
- bookmarking

I really don't see any advantage to doing it the way it is done now.  And as for the 
welcome files being in a subdirectory, does that really actually happen???  And if it 
did, then they don't have to turn on the forwarding, just leave it as default.  But 
please, please give us this option in the 4+ versions of Tomcat.

Travis Reeder


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PATCH] forward instead of redirect for welcome files

[Shapira, Yoav]

Howdy,
While I don't particularly care for this particular thread (and thus
don't mind the patch either way), I did point want to make a couple of
comments:

This should be a required feature.

Let's be very clear on what's required and what's not.  Per SRV.9.10,
Welcome Files, and specifically to quote:
The web container must send the request to the first
resource in the WAR that matches.

This does not mean a forward is required, not a redirect.  It is up to
the container implementation.  Tomcat is thus compliant with the
specification.  Whether it's the best implementation or not is up for
debate, and if there is significant preference to one implementation
(forward) over another (redirect), that the change should be made.  But
that preference is not the same as a specification requirement.

And as for the welcome files being in a subdirectory, does that really
actually happen???

Absolutely.  That happens frequently and the container implementation
must be able to support it.  Again, that's per SRV.9.10 which tomcat
implements.

But please, please give us this option in the 4+
versions of Tomcat.

From the patch implementation point of view, keep in mind that the
default servlet may be invoked too late in the request processing
pipeline (e.g. after filters that redirect), so for the patch to consist
solely of modifications to the DefaultServlet may be insufficient.  At
least I think so -- I may be wrong on this point.  In tomcat 5.x, this
will be a part of the mapper, which of course is invoked prior to any
client servlets.  The patch I've seen contributed relies on an
init-param to the DefaultServlet, and will probably work for most
configurations, but we need to be careful to cover all possible cases,
including the aforementioned filter possibility.

Yoav Shapira
Millennium ChemInformatics



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: RE: [PATCH] forward instead of redirect for welcome files

[travis]

Well something that is optional and works for most cases will make a lot of people 
happy.  It does not necessarily have to work for all cases at this time especially if 
the init param is only part of the params for the DefaultServlet itself, nothing else. 
 If a filter happens to redirect before it gets there, then so be it, but when it hits 
the defaultservlet, it should allow this behaviour if a person chooses to turn it on.

Travis

 Original Message 
From: Shapira, Yoav [EMAIL PROTECTED]
Sent: 2003-02-20
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: RE: [PATCH] forward instead of redirect for welcome files


Howdy,
While I don't particularly care for this particular thread (and thus
don't mind the patch either way), I did point want to make a couple of
comments:

This should be a required feature.  

Let's be very clear on what's required and what's not.  Per SRV.9.10,
Welcome Files, and specifically to quote:
The web container must send the request to the first
resource in the WAR that matches.

This does not mean a forward is required, not a redirect.  It is up to
the container implementation.  Tomcat is thus compliant with the
specification.  Whether it's the best implementation or not is up for
debate, and if there is significant preference to one implementation
(forward) over another (redirect), that the change should be made.  But
that preference is not the same as a specification requirement.

And as for the welcome files being in a subdirectory, does that really
actually happen???  

Absolutely.  That happens frequently and the container implementation
must be able to support it.  Again, that's per SRV.9.10 which tomcat
implements.

But please, please give us this option in the 4+
versions of Tomcat.

From the patch implementation point of view, keep in mind that the
default servlet may be invoked too late in the request processing
pipeline (e.g. after filters that redirect), so for the patch to consist
solely of modifications to the DefaultServlet may be insufficient.  At
least I think so -- I may be wrong on this point.  In tomcat 5.x, this
will be a part of the mapper, which of course is invoked prior to any
client servlets.  The patch I've seen contributed relies on an
init-param to the DefaultServlet, and will probably work for most
configurations, but we need to be careful to cover all possible cases,
including the aforementioned filter possibility.

Yoav Shapira
Millennium ChemInformatics



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PATCH] forward instead of redirect for welcome files

[Jan Grant]

On Thu, 20 Feb 2003, Shapira, Yoav wrote:


 Howdy,
 While I don't particularly care for this particular thread (and thus
 don't mind the patch either way), I did point want to make a couple of
 comments:

 This should be a required feature.

 Let's be very clear on what's required and what's not.  Per SRV.9.10,
 Welcome Files, and specifically to quote:
 The web container must send the request to the first
 resource in the WAR that matches.

Yeah, goodness only knows why that got dropped between the final public
review version and the finished document.

 From the patch implementation point of view, keep in mind that the
 default servlet may be invoked too late in the request processing
 pipeline (e.g. after filters that redirect), so for the patch to consist
 solely of modifications to the DefaultServlet may be insufficient.  At
 least I think so -- I may be wrong on this point.  In tomcat 5.x, this
 will be a part of the mapper, which of course is invoked prior to any
 client servlets.  The patch I've seen contributed relies on an
 init-param to the DefaultServlet, and will probably work for most
 configurations, but we need to be careful to cover all possible cases,
 including the aforementioned filter possibility.

I'm not sure exactly what the scenario you outline here is, but anyway:
it's not been my experience that people do complex things with filters
and still rely heavily on welcome-files - you may have different
experience - partly because of the redirect behaviour.

-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
Axioms speak louder than words.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] forward instead of redirect for welcome files

[Jan Grant]

On 7 Jan 2003, Matt Parker wrote:

 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.

Hopefully in time this can become turned on by default. This behaviour
almost made it into the last servlet spec but got dropped at some point
between candidate spec and the release.

Since user behaviour is typically to bookmark pages that they're looking
at, the redirect behaviour essentially makes the welcome file feature
useless (for all the reasons outlined in Cool URLs don't change).

-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
...You're visualising the _duck_ taped over my _mouth_..?


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [PATCH] forward instead of redirect for welcome files

[Remy Maucherat]

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.

- 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 :)


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


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [PATCH] forward instead of redirect for welcome files

[Remy Maucherat]

Matt Parker wrote:

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:


I'll -1 this patch unless the new behavior is made optional (and default 
to the current behavior).

Remy


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

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

[Matt Parker]

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

[Hans Bergsten]

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


--- 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]


--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software   http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
Details athttp://TheJSPBook.com/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

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

[Costin Manolache]

Matt Parker wrote:

 
 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.

 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.


The problem is that once again the servlet spec defines a behavior that 
is different from the common practices on web servers.

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.

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 ).

A third reason: it's safer :-)

Costin







--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

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

[Hans Bergsten]

Matt Parker wrote:

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.


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.

Anyway, I leave it to Costin to decide if it can be applied safely or
not.

Hans
--
Hans Bergsten[EMAIL PROTECTED]
Gefion Software   http://www.gefionsoftware.com/
Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0
Details athttp://TheJSPBook.com/


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [PATCH] forward instead of redirect for welcome files

[Costin Manolache]

Matt Parker wrote:

 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.

Well, it seems I'm wrong - Apache also allows relative paths in 
DirectoryIndex. 

And if the directory ends with /, the anchors would probably work.

My mistake.


 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.

Not necesarily faster - but if the file is a .shtml or .php - apache may
handle it better. 
Probably not a very good reason ( since not too many people are mixing java 
with non-java pages ).


 A third reason: it's safer :-)
 
 ?? how is it safer?

More predictible. 


 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 :)

If I remember corectly - this was how the first implementation of welcome 
files worked ( long, long ago ). After several strange bugs it changed to
do redirects. 

Tomcat3.3 has an option - useInternal - that will change the behavior (
I think it defaults to false ).

It could be a good idea to add this option in 5.0 ( or 4.1 ). 

Costin



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

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: [PATCH] forward instead of redirect for welcome files

[Costin Manolache]

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.

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.



Costin



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [PATCH] forward instead of redirect for welcome files

[Tim Funk]

If a trailing / is not present, then performing a 
RequestDispatcher.forward will break all relative references (for the 
web browser)

-Tim

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.

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.



Costin

 


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

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

[Matt Parker]

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

[Matt Parker]

 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

[Matt Parker]

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

[Tim Moore]

 -Original Message-
 From: Matt Parker [mailto:[EMAIL PROTECTED]] 
 Sent: Monday, January 06, 2003 7:39 PM
 To: Tomcat Developers List
 Subject: 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...
 

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

-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

 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

[Matt Parker]

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

[Tim Moore]

 -Original Message-
 From: Matt Parker [mailto:[EMAIL PROTECTED]] 
 Sent: Monday, January 06, 2003 8:11 PM
 To: Tomcat Developers List
 Subject: 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)

Well if you redirect from /foo to /foo/ and handle the welcome file from
/foo/ then all is well. :-)

 - Apache also has the problem with a relative link on a 
 welcome file which has a directory specified in it

Ah...yes I imagine so.

 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.

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.
-- 
Tim Moore / Blackboard Inc. / Software Engineer
1899 L Street, NW / 5th Floor / Washington, DC 20036
Phone 202-463-4860 ext. 258 / Fax 202-463-4863

--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

RE: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

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]

RE: [PATCH] forward instead of redirect for welcome files

[Costin Manolache]

Please at least make it optional - with the default beeing the current 
behavior.


Costin

Matt Parker wrote:

 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]

[PATCH] forward instead of redirect for welcome files

[Matt Parker]

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

[Jon Scott Stevens]

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


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]

Re: [PATCH] forward instead of redirect for welcome files

[Matt Parker]

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]