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