tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Bauman <>
Subject Re: Case Sensitivity in URLs (was RE: BugRat Report #92 was closed (apparently by: Craig R.)
Date Mon, 11 Sep 2000 15:36:42 GMT

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 <> 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
> (603) 673-6600
> -----Original Message-----
> >From: 
> >Sent:	Saturday, September 09, 2000 3:00 AM
> >To:	<>
> >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" <>
> >To: <>
> >Cc: "Z_Tomcat Alias" <>
> >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:
> >> 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:
> >> 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:
> For additional commands, e-mail:

View raw message