You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jonathan Pierce <Jo...@seagram.com> on 2000/09/11 19:10:06 UTC
Re[2]: Case Sensitivity in URLs (was RE: BugRat Report #92 w
I've encountered installation problems caused by case-sensitive Tomcat paths
that are not related to users typing URLs.
In my environment, we install Tomcat as an NT Service where one of the registry
parameters is the path to the current directory. I keep my Tomcat installation
in my wwwroot path so that I can easily promote versions of my application from
development to staging to production.
The operations staff at my company installs IIS and is not always consistent
across machines when specifying the case of directories above wwwroot when
creating web sites.
This causes a problem because they need to install a path specifc to how it was
typed on the particular machine whenever they install one of my Tomcat based
applications.
It would be much simpler and less error-prone if the path part of the resource
could be configured case-insensitive.
The part of the path that follows the context, should remain case-sensitive
since different Servlets might exist with the same name and different cases.
This would address much of the portability concerns.
This would solve the JDP security issue, since the filename and extension would
remain case-sensitive.
I'd still like to see the option of installing Tomcat with case-sensitivity for
at least the path part of the resource part of the URL.
Jonathan
____________________Reply Separator____________________
Subject: Re: Case Sensitivity in URLs (was RE: BugRat Report #92 was
Author: tomcat-dev@jakarta.apache.org
Date: 9/11/00 10:36 AM
Steve,
Very nicely argued.
However, I don't honestly believe you are really saving anyone any real,
discernable usability by allowing a context mapping to be
case-insensitive. If someone is going to type a context case-insensitive
and then somehow going to type the rest of the URL case-sensitive you will
"save" them. But really, what user fits into this catagory? They will
either consider all of it or not. The argument doesn't hold up. You aren't
helping anyone with this suggestion, you are only muddying the waters of
what a URL should be.
Furthermore, if we are going to "weigh the consideration carefully", then
we should carefully consider the root cause of why case sensitivity is an
issue at all for any Internet application and Windows. The reason this is
a problem is because Microsoft made a bad design decision years ago with a
8.3 case-insensitive filesystem and now they are stuck supporting it
forever. Why should the rest of the world have to suffer?
On Mon, 11 Sep 2000, Steve Fyfe wrote:
> I am the person who submitted this bug, and I'd like to respond to some of
> the comments so far.
>
> Craig McClanahan wrote in the comment closing bug 92:
> >According to the HTTP spec (RFC 2616, Section 3.2.3), the part of a URL
> >after the host and port is supposed to be case sensitive. Just because
> >IIS does not follow this is no reason to make Tomcat disobey it as well.
>
> The RFC says that except for the host and port, the URL SHOULD be case
> sensitive, not that it MUST be case sensitive. In the RFC, the word SHOULD
> has the following meaning:
>
> >3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
> > may exist valid reasons in particular circumstances to ignore a
> > particular item, but the full implications must be understood and
> > carefully weighed before choosing a different course.
>
> I believe the situation we have here is a valid reason for ignoring the RFC's
> recommendation. The problem comes up specifically because IIS chooses to
> ignore this recommendation. Granted, that by itself is no reason for Tomcat
> to do the same. However, as things stand today the situation is intolerable,
> in my opinion.
>
> If IIS forced case-sensitivity, then users would be forced to type the
> correct case in order to use a web application. But as long as they can
> ignore the case and still see the page they requested, they have no reason to
> pay attention to the case of the URL. In fact, the user may not even realize
> that the URL he typed is in the wrong case.
>
> A user can use the web app for quite a long time, as long as he only requests
> static pages. Then all of a sudden, he asks for what he perceives as just
> another page, and he gets a 404 because that page is really generated by a
> servlet managed by Tomcat. He has no reason to suspect that all-of-a-sudden
> the the system has started to enforce case sensitivity. To the user, this
> situation looks like a broken link -- in other words, it is a bug.
>
> AFAIK there is no way for the application developer to fix this "bug". My
> applications all use relative URLs to reference resources that are included
> in the web app, and those URLs are specified in the correct case. But
> currently, my relative URLs don't work if they are "relative to" an URL that
> the user typed in the wrong case. If anyone knows how to make this work,
> please let me know (but if you are going to suggest that I not use IIS, then
> don't bother. This is not an option for me. The web app I am developing must
> work on a variety of servers, including IIS).
>
>
> Danno <sh...@earthlink.net> said:
> >Originally tomcat was case insensitive in matching the urls to
> >servlets/files (or at least after the web-app descriptor and on windows).
> >The big problem was that it created a security hole with jsp files
>
> I am not proposing that the jsp problem should be re-introduced. I am only
> suggesting that the fix for the jsp problem has introduced another problem,
> and I am asking for a different fix that will solve both problems.
>
>
> I know nothing about the internal workings of Tomcat, and I'm sure that I
> don't appreciate all the ramifications of this issue, so I cannot suggest a
> solution. All I can do is point out that the current situation leaves me, and
> I presume many other developers, with a problem that I cannot solve.
>
> Until Microsoft decides to change IIS to be more compliant with the HTTP spec
> (extremely unlikely), this problem is only going to be resolved by changing
> Tomcat. Even if that means that Tomcat does not follow the recommendation for
> case-sensitive URLs.
>
> Since IIS is one of the more popular web servers, I believe it is in Tomcat's
> best interest to interoperate with IIS in a way that does not cause this
> problem. For this reason, the fix should be in the official version.
>
> In any case, IMHO this issue deserves careful consideration to determine the
> best course. This bug report should not be discounted just because the HTTP
> spec encourages case sensitivity in URLs.
>
> Steve
>
>
> Steve Fyfe
> CNI Corporation
> Milford New Hampshire
>
> SFyfe@cnicorp.com
> (603) 673-6600
>
>
> -----Original Message-----
> >From: shemnon@earthlink.net
> >Sent: Saturday, September 09, 2000 3:00 AM
> >To: <to...@jakarta.apache.org>
> >Subject: Re: Re[3]: BugRat Report #92 was closed (apparently by: Craig R.
> >
> > Originally tomcat was case insensitive in matching the urls to
> >servlets/files (or at least after the web-app descriptor and on windows).
> >The big problem was that it created a security hole with jsp files: foo.jsp
> >would send the compiled jsp but foo.Jsp would send back the un-compiled
> >source (this is because the url-mapping of the file extension was case
> >sensitive.) Unless any configuration option to turn on case insensitivity
> >cound be demonstrated to not re-create that security hole or open any others
> >I would be -1 the patch (it would need some extra flair like matching the
> >url mapping to the file name in addition to the url or re-writing the url to
> >the cannonical file case).
> > That is unless the activation switch was actually named "make
> >insecure," "create security hole," or "an option that could cost you your
> >job and your former emplyer's reputation" or something similar. Another
> >option is that setting it comes with all sorts of warnings on activation
> >saying "tomcat is now insecure" and generally annoying messages to the
> >administrator telling them that they are doing something bad so that when
> >someone gets burned by it we all can say "well duh! We told you so." I
> >would much rather prefer forcing case sensitivity, there's less issues
> >involved.
> >
> >--Danno
> >
> >----- Original Message -----
> >From: "Jonathan Pierce" <Jo...@seagram.com>
> >To: <to...@jakarta.apache.org>
> >Cc: "Z_Tomcat Alias" <to...@cortexity.com>
> >Sent: Friday, September 08, 2000 6:38 PM
> >Subject: Re[3]: BugRat Report #92 was closed (apparently by: Craig R.
> >
> >
> >> Craig,
> >>
> >> I'm not the person who posted the bug report and I agree with you that
> >> case-sensitive urls is not a bug.
> >>
> >> I just thought it might be a nice configurable option to have available
> >for
> >> users who want to configure case insensitivity for case insensitive file
> >> systems. The default behavior can still be case-sensitivity if you feel
> >the
> >> performance would be impacted.
> >>
> >> Jonathan
> >>
> >> ____________________Reply Separator____________________
> >> Subject: Re[2]: BugRat Report #92 was closed (apparently by: Craig R.
> >> Author: tomcat-dev@jakarta.apache.org
> >> Date: 9/8/00 8:23 PM
> >>
> >> According to the html 4.0 spec:
> >>
> >> "There may be URIs, or parts of URIs, where case doesn't matter (e.g.,
> >machine
> >> names), but identifying these may not be easy. Users should always
> >consider that
> >> URIs are case-sensitive (to be on the safe side)."
> >>
> >> This sounds to me like it is not required that URLs be case sensitive,
> >only that
> >> users should assume that they are just in case.
> >>
> >> It wouldn't hurt to support case-insensivity for the part of the URL that
> >> precedes the context on file systems such as NT which are not case
> >sensitive.
> >> Maybe there could be a configurable option as to whether or not to enforce
> >case
> >> for the part of the url that precedes the context.
> >>
> >> Jonathan
> >>
> >> ____________________Reply Separator____________________
> >> Subject: Re: BugRat Report #92 was closed (apparently by: Craig R. Mc
> >> Author: tomcat-dev@jakarta.apache.org
> >> Date: 9/8/00 5:17 PM
> >>
> >> Jonathan Pierce wrote:
> >>
> >> > Paths on NT are not case sensitive.
> >> >
> >>
> >> Agreed, but that's not the point. Resource paths used in HTTP are case
> >> sensitive.
> >>
> >> >
> >> > Only the part of the URL after the /servlet needs to be case sensitive.
> >> >
> >>
> >> How do you figure that? From the point of view of HTTP, the context path
> >> and the "/servlet" prefix are part of the resource path -- the protocol
> >> makes absolutely no distinction between it and the remainder of the path.
> >>
> >> If HTTP were a MIcrosoft-only protocol, I'd be in agreement with you. But
> >> it's not. Tomcat needs to play by the official specification's rules.
> >> >
> >> > This also causes a problem when configuring Tomcat to startup as a
> >service if
> >> > the app directory parameter is not typed in the correct case.
> >> >
> >>
> >> Is there something so terribly hard about typing it in the correct case
> >> when you run into this? :-)
> >>
> >> >
> >> > Can this be changed to support case insensitivity for the part of the
> >part
> >> that
> >> > precedes the context?
> >> >
> >>
> >> Can it be changed? Sure. Will it be changed? Not in the official
> >> distribution,
> >> if my -1 counts for anything (which it does).
> >>
> >> Because this is open source, you are welcome to create yourself a patch to
> >make
> >> your version of Tomcat non-standard in this respect. But you're not going
> >to
> >> like
> >> the performance impact this has on figuring out what webapp a request
> >belongs
> >> to,
> >> or what servlet to execute.
> >>
> >> >
> >> > Jonathan
> >> >
> >>
> >> Craig McClanahan
> >>
> >> ====================
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: Re[2]: Case Sensitivity in URLs (was RE: BugRat Report #92 w
Posted by Nick Bauman <ni...@cortexity.com>.
Jonathan, Steve
You have legitimate concerns. Speaking only for myself, in light of the
information you present, I am of the opinion in the end it doesn't matter
(to me) if the process makes the context case-insensitive for Windows
only (note however, it just goes to prove my point even better: allowing
the "fix" would only be a "work around", not a solution, as the problem's
root is bad design.) If my vote matters at all (which it doesn't), I don't
care as long as it's /untouched/ ie: /not-screwed-up/ for Unix developers.
I know now I won't be choosing Windows as a platform for my deployment of
Tomcat any time soon, /especially/ if you get your way, for all the
reasons Craig cites ;)
On Mon, 11 Sep 2000, Jonathan Pierce wrote:
> I've encountered installation problems caused by case-sensitive Tomcat paths
> that are not related to users typing URLs.
>
> In my environment, we install Tomcat as an NT Service where one of the registry
> parameters is the path to the current directory. I keep my Tomcat installation
> in my wwwroot path so that I can easily promote versions of my application from
> development to staging to production.
>
> The operations staff at my company installs IIS and is not always consistent
> across machines when specifying the case of directories above wwwroot when
> creating web sites.
>
> This causes a problem because they need to install a path specifc to how it was
> typed on the particular machine whenever they install one of my Tomcat based
> applications.
>
> It would be much simpler and less error-prone if the path part of the resource
> could be configured case-insensitive.
>
> The part of the path that follows the context, should remain case-sensitive
> since different Servlets might exist with the same name and different cases.
>
> This would address much of the portability concerns.
>
> This would solve the JDP security issue, since the filename and extension would
> remain case-sensitive.
>
> I'd still like to see the option of installing Tomcat with case-sensitivity for
> at least the path part of the resource part of the URL.
>
> Jonathan
>
> ____________________Reply Separator____________________
> Subject: Re: Case Sensitivity in URLs (was RE: BugRat Report #92 was
> Author: tomcat-dev@jakarta.apache.org
> Date: 9/11/00 10:36 AM
>
> Steve,
>
> Very nicely argued.
>
> However, I don't honestly believe you are really saving anyone any real,
> discernable usability by allowing a context mapping to be
> case-insensitive. If someone is going to type a context case-insensitive
> and then somehow going to type the rest of the URL case-sensitive you will
> "save" them. But really, what user fits into this catagory? They will
> either consider all of it or not. The argument doesn't hold up. You aren't
> helping anyone with this suggestion, you are only muddying the waters of
> what a URL should be.
>
> Furthermore, if we are going to "weigh the consideration carefully", then
> we should carefully consider the root cause of why case sensitivity is an
> issue at all for any Internet application and Windows. The reason this is
> a problem is because Microsoft made a bad design decision years ago with a
> 8.3 case-insensitive filesystem and now they are stuck supporting it
> forever. Why should the rest of the world have to suffer?
>
> On Mon, 11 Sep 2000, Steve Fyfe wrote:
>
> > I am the person who submitted this bug, and I'd like to respond to some of
> > the comments so far.
> >
> > Craig McClanahan wrote in the comment closing bug 92:
> > >According to the HTTP spec (RFC 2616, Section 3.2.3), the part of a URL
> > >after the host and port is supposed to be case sensitive. Just because
> > >IIS does not follow this is no reason to make Tomcat disobey it as well.
> >
> > The RFC says that except for the host and port, the URL SHOULD be case
> > sensitive, not that it MUST be case sensitive. In the RFC, the word SHOULD
> > has the following meaning:
> >
> > >3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
> > > may exist valid reasons in particular circumstances to ignore a
> > > particular item, but the full implications must be understood and
> > > carefully weighed before choosing a different course.
> >
> > I believe the situation we have here is a valid reason for ignoring the RFC's
> > recommendation. The problem comes up specifically because IIS chooses to
> > ignore this recommendation. Granted, that by itself is no reason for Tomcat
> > to do the same. However, as things stand today the situation is intolerable,
> > in my opinion.
> >
> > If IIS forced case-sensitivity, then users would be forced to type the
> > correct case in order to use a web application. But as long as they can
> > ignore the case and still see the page they requested, they have no reason to
> > pay attention to the case of the URL. In fact, the user may not even realize
> > that the URL he typed is in the wrong case.
> >
> > A user can use the web app for quite a long time, as long as he only requests
> > static pages. Then all of a sudden, he asks for what he perceives as just
> > another page, and he gets a 404 because that page is really generated by a
> > servlet managed by Tomcat. He has no reason to suspect that all-of-a-sudden
> > the the system has started to enforce case sensitivity. To the user, this
> > situation looks like a broken link -- in other words, it is a bug.
> >
> > AFAIK there is no way for the application developer to fix this "bug". My
> > applications all use relative URLs to reference resources that are included
> > in the web app, and those URLs are specified in the correct case. But
> > currently, my relative URLs don't work if they are "relative to" an URL that
> > the user typed in the wrong case. If anyone knows how to make this work,
> > please let me know (but if you are going to suggest that I not use IIS, then
> > don't bother. This is not an option for me. The web app I am developing must
> > work on a variety of servers, including IIS).
> >
> >
> > Danno <sh...@earthlink.net> said:
> > >Originally tomcat was case insensitive in matching the urls to
> > >servlets/files (or at least after the web-app descriptor and on windows).
> > >The big problem was that it created a security hole with jsp files
> >
> > I am not proposing that the jsp problem should be re-introduced. I am only
> > suggesting that the fix for the jsp problem has introduced another problem,
> > and I am asking for a different fix that will solve both problems.
> >
> >
> > I know nothing about the internal workings of Tomcat, and I'm sure that I
> > don't appreciate all the ramifications of this issue, so I cannot suggest a
> > solution. All I can do is point out that the current situation leaves me, and
> > I presume many other developers, with a problem that I cannot solve.
> >
> > Until Microsoft decides to change IIS to be more compliant with the HTTP spec
> > (extremely unlikely), this problem is only going to be resolved by changing
> > Tomcat. Even if that means that Tomcat does not follow the recommendation for
> > case-sensitive URLs.
> >
> > Since IIS is one of the more popular web servers, I believe it is in Tomcat's
> > best interest to interoperate with IIS in a way that does not cause this
> > problem. For this reason, the fix should be in the official version.
> >
> > In any case, IMHO this issue deserves careful consideration to determine the
> > best course. This bug report should not be discounted just because the HTTP
> > spec encourages case sensitivity in URLs.
> >
> > Steve
> >
> >
> > Steve Fyfe
> > CNI Corporation
> > Milford New Hampshire
> >
> > SFyfe@cnicorp.com
> > (603) 673-6600
> >
> >
> > -----Original Message-----
> > >From: shemnon@earthlink.net
> > >Sent: Saturday, September 09, 2000 3:00 AM
> > >To: <to...@jakarta.apache.org>
> > >Subject: Re: Re[3]: BugRat Report #92 was closed (apparently by: Craig R.
> > >
> > > Originally tomcat was case insensitive in matching the urls to
> > >servlets/files (or at least after the web-app descriptor and on windows).
> > >The big problem was that it created a security hole with jsp files: foo.jsp
> > >would send the compiled jsp but foo.Jsp would send back the un-compiled
> > >source (this is because the url-mapping of the file extension was case
> > >sensitive.) Unless any configuration option to turn on case insensitivity
> > >cound be demonstrated to not re-create that security hole or open any others
> > >I would be -1 the patch (it would need some extra flair like matching the
> > >url mapping to the file name in addition to the url or re-writing the url to
> > >the cannonical file case).
> > > That is unless the activation switch was actually named "make
> > >insecure," "create security hole," or "an option that could cost you your
> > >job and your former emplyer's reputation" or something similar. Another
> > >option is that setting it comes with all sorts of warnings on activation
> > >saying "tomcat is now insecure" and generally annoying messages to the
> > >administrator telling them that they are doing something bad so that when
> > >someone gets burned by it we all can say "well duh! We told you so." I
> > >would much rather prefer forcing case sensitivity, there's less issues
> > >involved.
> > >
> > >--Danno
> > >
> > >----- Original Message -----
> > >From: "Jonathan Pierce" <Jo...@seagram.com>
> > >To: <to...@jakarta.apache.org>
> > >Cc: "Z_Tomcat Alias" <to...@cortexity.com>
> > >Sent: Friday, September 08, 2000 6:38 PM
> > >Subject: Re[3]: BugRat Report #92 was closed (apparently by: Craig R.
> > >
> > >
> > >> Craig,
> > >>
> > >> I'm not the person who posted the bug report and I agree with you that
> > >> case-sensitive urls is not a bug.
> > >>
> > >> I just thought it might be a nice configurable option to have available
> > >for
> > >> users who want to configure case insensitivity for case insensitive file
> > >> systems. The default behavior can still be case-sensitivity if you feel
> > >the
> > >> performance would be impacted.
> > >>
> > >> Jonathan
> > >>
> > >> ____________________Reply Separator____________________
> > >> Subject: Re[2]: BugRat Report #92 was closed (apparently by: Craig R.
> > >> Author: tomcat-dev@jakarta.apache.org
> > >> Date: 9/8/00 8:23 PM
> > >>
> > >> According to the html 4.0 spec:
> > >>
> > >> "There may be URIs, or parts of URIs, where case doesn't matter (e.g.,
> > >machine
> > >> names), but identifying these may not be easy. Users should always
> > >consider that
> > >> URIs are case-sensitive (to be on the safe side)."
> > >>
> > >> This sounds to me like it is not required that URLs be case sensitive,
> > >only that
> > >> users should assume that they are just in case.
> > >>
> > >> It wouldn't hurt to support case-insensivity for the part of the URL that
> > >> precedes the context on file systems such as NT which are not case
> > >sensitive.
> > >> Maybe there could be a configurable option as to whether or not to enforce
> > >case
> > >> for the part of the url that precedes the context.
> > >>
> > >> Jonathan
> > >>
> > >> ____________________Reply Separator____________________
> > >> Subject: Re: BugRat Report #92 was closed (apparently by: Craig R. Mc
> > >> Author: tomcat-dev@jakarta.apache.org
> > >> Date: 9/8/00 5:17 PM
> > >>
> > >> Jonathan Pierce wrote:
> > >>
> > >> > Paths on NT are not case sensitive.
> > >> >
> > >>
> > >> Agreed, but that's not the point. Resource paths used in HTTP are case
> > >> sensitive.
> > >>
> > >> >
> > >> > Only the part of the URL after the /servlet needs to be case sensitive.
> > >> >
> > >>
> > >> How do you figure that? From the point of view of HTTP, the context path
> > >> and the "/servlet" prefix are part of the resource path -- the protocol
> > >> makes absolutely no distinction between it and the remainder of the path.
> > >>
> > >> If HTTP were a MIcrosoft-only protocol, I'd be in agreement with you. But
> > >> it's not. Tomcat needs to play by the official specification's rules.
> > >> >
> > >> > This also causes a problem when configuring Tomcat to startup as a
> > >service if
> > >> > the app directory parameter is not typed in the correct case.
> > >> >
> > >>
> > >> Is there something so terribly hard about typing it in the correct case
> > >> when you run into this? :-)
> > >>
> > >> >
> > >> > Can this be changed to support case insensitivity for the part of the
> > >part
> > >> that
> > >> > precedes the context?
> > >> >
> > >>
> > >> Can it be changed? Sure. Will it be changed? Not in the official
> > >> distribution,
> > >> if my -1 counts for anything (which it does).
> > >>
> > >> Because this is open source, you are welcome to create yourself a patch to
> > >make
> > >> your version of Tomcat non-standard in this respect. But you're not going
> > >to
> > >> like
> > >> the performance impact this has on figuring out what webapp a request
> > >belongs
> > >> to,
> > >> or what servlet to execute.
> > >>
> > >> >
> > >> > Jonathan
> > >> >
> > >>
> > >> Craig McClanahan
> > >>
> > >> ====================
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>