Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4FE09EF8.3060501@christopherschultz.net>
Date: Tue, 19 Jun 2012 11:47:04 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Modify HTTP status returned by stopped context
References: 
 <OFEF9E5349.75208499-ON86257A1D.006935BB-86257A1D.006BCC4A@LocalDomain>
 <4FDA4584.7070803@apache.org>
 <OF1E0BB98B.161374FA-ON86257A1E.005890B1-86257A1E.005AB19F@LocalDomain>
 <4FDBB00C.7070304@christopherschultz.net>
 <OF424E99D0.D0206AE3-ON86257A21.006682DD-86257A21.006D2C3C@LocalDomain>
 <4FDFCAF9.3040607@christopherschultz.net>
 <OF29B2C22D.6957103B-ON86257A22.00477B70-86257A22.0049D641@LocalDomain>
In-Reply-To: 
 <OF29B2C22D.6957103B-ON86257A22.00477B70-86257A22.0049D641@LocalDomain>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kyle,

On 6/19/12 9:26 AM, kharper2@oreillyauto.com wrote:
> "Where did you configure this? Which webapp's web.xml?" In the ROOT
> context (/).  I'm on Ubuntu 10.04 with defaults, so
> /var/lib/tomcat6/webapps/ROOT/WEB-INF/web.xml

Ok.

> "Yes, the longest match should win." We keep saying "the longest
> match should win", but looking at the configuration it seems
> illogical.  If I configure the following: ROOT context:  /foo/*
> (My special servlet) foo context:  /  (DefaultServlet)

Sorry, longest match wins for URI matching once the webapp has been
selected. The webapp is selected using the left-most part of the path,
with ROOT being the fall-through case: if you have /foo deployed and
/foo in ROOT, I would expect your /foo webapp to receive the request.
It's clear that's happening even from your failure cases.

> Based on my testing this isn't the case.  So is it accurate to say
> tomcat's logic is (or we expect it to be): 1.  Look for a context
> that matches the URL base pattern. 2.  If not found, search all
> contexts for servlets with URL patterns that can service the
> request and select the one with the longest match.

No, the webapp is selected first, then the path is trimmed (if
necessary) and then the longest-match wins when matching against
url-patterns configured in that webapp's web.xml.

> As for testing on 6.0.35 and 7.0.28, yea I can do that.  I'll set
> all that up and submit a bug report if I can't get the intended
> behavior to work. But this bring up another point:  wouldn't it be
> more accurate for tomcat return HTTP Status Code 503 for a context
> that has been deployed but is in the stopped/errored state?
> Strictly speaking, it isn't "not found" but rather "unavailable".

It's not really clear to me from the spec what to do about a "stopped"
webapp that is still technically deployed. I'm not sure if Tomcat
differentiates between a stopped webapp deployed to /foo and no webapp
at all for /foo. There was a recent bugfix to TC 7[1] to fix something
related, but that was during redeployment and I suspect that if the
webapp is stopped you'd get some other behavior. I tend not to stop
webapps so I've never bothered to play around with it.

> If there is a better forum/group to have this discussion with let
> me know.

No, this is definitely the place to have this discussion.

Thanks,
- -chris

[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=53024
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/gnvgACgkQ9CaO5/Lv0PBVDACgmH/cm8k2zOagH7Qprh7Mxd0Q
LNIAoKTiBBFQDrpktd0THnwNo3t6t+Bk
=QpwI
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org