tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "neal" <nealcab...@yahoo.com>
Subject RE: RewriteRules and Standalone Tomcat
Date Thu, 09 Jan 2003 07:38:13 GMT
In you previous email you say:

"This still screws up relative references for people that use wierd welcome
file paths like 'foo/bar.html', but will work for the majority".

What do you mean by "wierd  welcome file paths". Will most relative paths
still work?   Is this the same sort of relative file path issues I would see
if I forwarded (rather than redirect) from one JSP to another?  If so,
wouldn't this only be an issue if the welcome file was located somewhere
other than the root of the application?

Neal


-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Wednesday, January 08, 2003 11:24 PM
To: Tomcat Users List
Subject: RE: RewriteRules and Standalone Tomcat




On Wed, 8 Jan 2003, neal wrote:

> Date: Wed, 8 Jan 2003 23:11:44 -0800
> From: neal <nealcabage@yahoo.com>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> Subject: RE: RewriteRules and Standalone Tomcat
>
> 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.  :)
>

You will change that opinion as soon as you realize that relative URIs in
your welcome pages do not work any more :-).

>
> "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 is the right answer, IMHO.

It also includes the use case where you just say:

  http://www.mycompany.com

which is (essentially) a request for the welcome file of the top-level
directory of the ROOT webapp.  This should be redirected to:

  http://www.mycompany.com/

just like Apache does it, and then forwarded to the welcome file from
there, so that relative URIs still work as expected.

Craig

> -----Original Message-----
> From: Craig R. McClanahan [mailto:craigmcc@apache.org]
> 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" <JTurner@AAS.com>
> > Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> > To: 'Tomcat Users List' <tomcat-user@jakarta.apache.org>
> > 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:craigmcc@apache.org]
> > 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" <JTurner@AAS.com>
> > > Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> > > To: 'Tomcat Users List' <tomcat-user@jakarta.apache.org>
> > > 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:tomcat-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:tomcat-user-help@jakarta.apache.org>
> >
> > ---
> > 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:tomcat-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:tomcat-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message