tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Bauman <n...@cortexity.com>
Subject Re: Re[2]: Case Sensitivity in URLs (was RE: BugRat Report #92 w
Date Mon, 11 Sep 2000 18:48:14 GMT
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 <shemnon@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:  <tomcat-dev@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" <Jonathan_Pierce@seagram.com>
> > >To: <tomcat-dev@jakarta.apache.org>
> > >Cc: "Z_Tomcat Alias" <tomcat-bugs@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
> 



Mime
View raw message