tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Case Sensitivity in URLs (was RE: BugRat Report #92 was closed(apparently by: Craig R.)
Date Mon, 11 Sep 2000 16:51:40 GMT
See below.

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.

Steve's understanding of the RFC language is correct.  Tomcat currently follows this
recommendation universally.

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

And this fact is the strongest reason *not* to change Tomcat IMHO.

Consider the demonstrated fact that most developers who write servlet/JSP apps do
not read the specs :-).  If they happen to write their webapp first on a Windows
platform, and either wittingly or unwittingly rely on case insensitivity, they're
going to run into problems the moment they try to port their app to any other
platform.  In essence, the fact that IIS does not enforce case sensitivity is a
subtle platform lock-in.

Tomcat should not accomodate this in the official release, because doing so doesn't
solve the portability problem.  The correct thing to do (as is pointed out by
Steve's use of the term "wrong" case) is to require the use of the correct 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.

I've got slightly more sympathy for the user in this scenario.  However, webapps
tend to behave differently from websites -- apps expect you to follow the links that
are generated by the application once you are inside (if users find themselves
having to manually enter URLs or use the back and forward arrows, you probably need
to improve your internal navigation).  The generated links are the developer's

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

(1) Render a <base> element (inside <head>) that specifies what the
   correct base is, in the correct case.

(2) Reduce the requirements for users typing URLs in the first place
   by providing them enough links so that they don't have to.

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

Doing this would violate one of the key value propositions of Java -- portability.
That is much more important to me than working around this "feature" of the Windows

> 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

Craig McClanahan

See you at ApacheCon Europe <>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat

View raw message