So, in this scenario .. if a url without a directory is given and without a trailign slash, the redirect would not occur? That would fix this issue. I could certainly get behind that. :)
"if the final element of the path is a "directory" (or a context) without a trailing slash, redirect to the same path with a trailing slash. But if the path is given with a trailing slash, forward to the welcome file." -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 08, 2003 7:36 PM To: Tomcat Users List Subject: RE: RewriteRules and Standalone Tomcat On Wed, 8 Jan 2003, Turner, John wrote: > Date: Wed, 8 Jan 2003 22:19:47 -0500 > From: "Turner, John" <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > Subject: RE: RewriteRules and Standalone Tomcat > > > OK, so what's the rationalization for the 302? Can you shed some light on > that? Consider a typical welcome page that includes: <body> ... <img src="logo.jpg"> ... </body> For a context path "/myapp", consider what happens when I type "http://www.mycompany.com/myapp"; in to the browser. With a forward, the relative reference to logo.jpg gets resolved "wrong" (from the user's perspective) because it's the *browser* that resolves it. Want proof? Go back about three years when Tomcat 3.0 and 3.1 behaved this way, and "why don't images in a welcome page work" was a FAQ on TOMCAT-USER :-). Changing to the current behavior was the result of a bug report about this, that had widespread support from the user community at the time. Assuming that we can be compatible with the servlet spec language (for 2.4, that means convince the EG to clarify it this way), I think the right answer is the one proposed in the TOMCAT-DEV discussion -- if the final element of the path is a "directory" (or a context) without a trailing slash, redirect to the same path with a trailing slash. But if the path is given with a trailing slash, forward to the welcome file. This still screws up relative references for people that use wierd welcome file paths like "foo/bar.html", but will work for the majority -- and it seems to be the way that Apache and other web servers deal with the issue. > > John Craig > > > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 08, 2003 9:07 PM > To: Tomcat Users List > Subject: RE: RewriteRules and Standalone Tomcat > > > > > On Wed, 8 Jan 2003, Turner, John wrote: > > > Date: Wed, 8 Jan 2003 20:33:50 -0500 > > From: "Turner, John" <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: 'Tomcat Users List' <[EMAIL PROTECTED]> > > Subject: RE: RewriteRules and Standalone Tomcat > > > > > > No problem, glad to help. Remember, Tomcat is not a HTTP server. It > > supports HTTP as a matter of convenience. You can run Tomcat all day > > long without a HTTP or HTTPS connector, and as far as I know, there is > > nothing in the spec that says Tomcat has to meet certain requirements > > for HTTP or HTTPS. CoyoteConnector is HTTP/1.1 compliant, but again, > > that's more for convenience and compatibility than a design > > requirement. > > > > Auoting from Servlet Specification, Version 2.3, Section 1.2: > > All servlet containers must support HTTP as a protocol > for requests and responses, but additional request/response > based protocols (such as HTTPS (HTTP over SSL) may be > supported. The minimum required version of the HTTP > specification that a container must implement is HTTP/1.0. > It is strongly suggested that containers implement the > HTTP/1.1 specification as well. > > So, a servlet container (which is either Tomcat standalone or > Tomcat+Apache) *must* support HTTP. > > > I'm sure the folks on tomcat-dev could shed some more light on it. > > > > Of course, this statement does nothing to resolve the issue of what the > right welcome file behavior is -- the HTTP spec is silent about that :-). > > > John > > Craig > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.434 / Virus Database: 243 - Release Date: 12/25/2002 > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.434 / Virus Database: 243 - Release Date: 12/25/2002 > > > -- > 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]>
