tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Modify HTTP status returned by stopped context
Date Tue, 19 Jun 2012 15:47:04 GMT
-----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


Mime
View raw message