You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by kh...@oreillyauto.com on 2012/06/14 21:37:26 UTC
Modify HTTP status returned by stopped context
Hello,
I am running multiple web applications on a tomcat server. When a request
to a context in the stopped state is made, tomcat is returning 404 "not
found" rather than 503 "unavailable". Is it possible to change this
behavior in any way? Obviously I can't just modify _all_ HTTP 404
responses to 503. Just those which are coming from a context in the
stopped state.
Here is a little more information, as to my goal.
I have a couple of web servers (apache 2.2.22) in front of a couple tomcat
servers (6.0.24). I am hosting multiple web applications. If an
application goes down or is stopped on "tocmat1", apache will continue to
send requests to "tomcat1", giving my users error pages. To partly solve
this, I've added the 'failonstatus' attribute to the balancer such that
HTTP 503 responses will put the BalancerMember in the error state for 60
seconds; thereby sending all requests to "tomcat2" which is replicating
sessions (this works very nicely, btw).
Unfortunately, tomcat is responding with HTTP 404 when a request is made to
a context that is stopped. I was surprised by this, given that the
requested context isn't "not found", it's simply (and probably
intentionally) "unavailable". I realize this could start a semantics
argument, which isn't my goal. I simply want to be able to avert traffic
from a context/server that has an application stopped.
Information
Web Servers: apache 2.2.22
App Servers: tomcat 6.0.24
Connector: ajp 1.3
OS: Ubuntu 12.04 LTS 64-bit (web servers) and Ubuntu 10.04 LTS 64-bit
(app servers)
(If I missed any info let me know)
Thank you,
Kyle Harper
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Modify HTTP status returned by stopped context
Posted by kh...@oreillyauto.com.
Mark,
Very slick. I wasn't aware of the longest-matching logic. I'll give this
a whirl and report back.
Thanks,
Kyle Harper
From: Mark Thomas <ma...@apache.org>
To: Tomcat Users List <us...@tomcat.apache.org>
Date: 06/14/2012 03:19 PM
Subject: Re: Modify HTTP status returned by stopped context
On 14/06/2012 20:37, kharper2@oreillyauto.com wrote:
>
> Hello,
>
> I am running multiple web applications on a tomcat server. When a
request
> to a context in the stopped state is made, tomcat is returning 404 "not
> found" rather than 503 "unavailable". Is it possible to change this
> behavior in any way? Obviously I can't just modify _all_ HTTP 404
> responses to 503. Just those which are coming from a context in the
> stopped state.
Assume the context in question is /foo
In the ROOT web application add a servlet with a mapping of /foo/*
The servlet should just return a 503 (or any other error code)
This works because the mapping rules require the longest match to the
context be considered first. While /foo is running, requests will be
mapped to the /foo context and the servlet in the ROOT web application
is ignored. When /foo is not running, the request is mapped to the
servlet in the ROOT web app.
This obviously won't work for stopping the ROOT web app.
HTH,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Modify HTTP status returned by stopped context
Posted by kh...@oreillyauto.com.
Hello Chris,
> 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.
...
> Sorry, longest match wins for URI matching once the webapp has been
selected.
Makes sense. I wanted to make sure I was following the logic correctly.
> 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 think I read about that bug fix in TC7. I believe it changed threads to
paused when a context was reload/restarting or something like that;
instead of sending a 404 immediately, if I recall correctly.
> I tend not to stop
> webapps so I've never bothered to play around with it.
The two scenarios that lead me to all of this in the first place were dead
applications (crashed web apps) and situations where a WAR is experiencing
problems and must be stopped for some period of time (possibly because
back-end resources are unavailable or whatever). The former is, sadly,
more frequent than the latter.
> No, this is definitely the place to have this discussion.
Here's a little back-story to help understand my approach:
I have a few web servers (apache httpd) sitting in front of a handful of
application servers. The web servers are currently configured to use a
single Proxy Balancer with a few Balancer Members for each "cluster" of
tomcat servers. Tomcat has, of course, been configured to replicate all
sessions in each cluster. I can drop app nodes left and right and as long
as 1 is still up, requests still get serviced. The problem here, is that
if a single server has an application crash Apache will continue to send
requests through that Balancer Member resulting in intermittent "404"s for
people.
Here's where the "magic" I am attempting to setup comes in... Assuming
Tomcat will return HTTP 503 for a crashed/stopped application, I can tell
Apache to "failonstatus" 503, which will put the worker thread for the
Balancer Member into the error state for a while, thereby preventing that
server from being used. The problem this causes is, if even 1 application
crashes or needs to be stopped on all servers, then all servers in the
cluster will be marked unavailable by the BalancerMember thread and no
other apps in the cluster will serve requests. To fix this, I take it one
step further, by creating an entire Proxy Balancer for *each* web
application and the Balancer Members are now on a per-context basis, so to
speak. So when /foo crashes on "tomcat1" the BalancerMember entering the
"error" state only affects requests to the foo context on the "tomcat1"
server.
I haven't seen anyone set it up like this exactly, but it sure seems like a
really, really good way to achieve High Availability on a granular level.
And as I read through the apache httpd docs and learned about Tomcat's
clustering, I figured this was all an intentional design philosophy for
others to follow. So I was certainly confused when I saw Tomcat returning
404 for things it could "find", but were "unavailable". I had one person
report that WebSphere returns 503 for applications turned "off", and I read
an old article that JBoss does the same; I have no direct proof of either.
So I'm wondering if they've tried to do with their packages what I'm trying
to accomplish with Apache httpd and tomcat.
Thoughts?
Kyle Harper
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Modify HTTP status returned by stopped context
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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
Re: Modify HTTP status returned by stopped context
Posted by kh...@oreillyauto.com.
Chris,
First, thanks again for your help. I appreciate it.
To answer your questions:
"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
"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)
It would seem like the ROOT context would always try to respond first,
since it has the longest matching URL pattern. Even if you extrapolate
from the context name you're left comparing these two things:
ROOT context: /foo/*
foo context: /foo/
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.
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". If there is a better forum/group to have this
discussion with let me know.
I'll report back with my test results. Thanks!
Kyle Harper
From: Christopher Schultz <ch...@christopherschultz.net>
To: Tomcat Users List <us...@tomcat.apache.org>
Date: 06/18/2012 07:49 PM
Subject: Re: Modify HTTP status returned by stopped context
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kyle,
On 6/18/12 3:52 PM, kharper2@oreillyauto.com wrote:
> Thank you for the direction. I created my own servlet which loads
> without error. Here is how I've configured it:
Where did you configure this? Which webapp's web.xml?
> <servlet> <servlet-name>HttpResponseAdjuster</servlet-name>
> <servlet-class>bla.bla.tomcat.ReturnNotAvailableServlet</servlet-class>
>
>
<load-on-startup>1</load-on-startup>
You don't need to load this on startup if you don't want to: the
servlet will be initialized when necessary.
> </servlet>
>
> <servlet-mapping>
> <servlet-name>HttpResponseAdjuster</servlet-name>
> <url-pattern>/foo/*</url-pattern> </servlet-mapping>
>
> <servlet-mapping>
> <servlet-name>HttpResponseAdjuster</servlet-name>
> <url-pattern>/Testing/*</url-pattern> </servlet-mapping>
>
> Unfortunately, when I stop the "foo" context, tomcat is still
> returning the default HTTP 404 page. It doesn't appear to give any
> consideration to the servlet mapping in my ROOT context. Unless
> I've configured something wrong, it appears the desired behavior
> (to look for /Context first, then a ROOT servlet with mapping of
> /Context/*) isn't happening.
Yes, the longest match should win.
> You'll notice I setup another servlet-mapping called /Testing/*.
> "Testing" is NOT a context. When I go to myserver:8080/Testing my
> servlet handles the request and does what I desire (HTTP 503). To
> reiterate, my version of tomcat is 6.0.24. Perhaps the logic we're
> relying on wasn't introduced until later? Or maybe I'm missing a
> configuration option at a higher level to send failed requests to
> search the ROOT context for mappings?
Assuming you have everything configured as described, then your
expected behavior is also what I'd expect. Please test with latest
6.0 which is 6.0.35. If that doesn't work, please also test with
7.0.28 (freshly minted this weekend) and let us know if you have more
success.
If it does not work with 6.0.35 or it does not work with 7.0.28, can
you create a simple test case (ROOT.war + some other WAR w/overlapping
URI spaces) and create a Bugzilla ticket for it (or 2, if the bug
exists in both versions)?
- -chris
-----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/fyvkACgkQ9CaO5/Lv0PBkvwCgiZ9fDieTRdPSJTkrphxRn7Yi
CoUAoJy5RTwqSwSLCJe5hrnpmw747k4O
=5ESc
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Modify HTTP status returned by stopped context
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kyle,
On 6/18/12 3:52 PM, kharper2@oreillyauto.com wrote:
> Thank you for the direction. I created my own servlet which loads
> without error. Here is how I've configured it:
Where did you configure this? Which webapp's web.xml?
> <servlet> <servlet-name>HttpResponseAdjuster</servlet-name>
> <servlet-class>bla.bla.tomcat.ReturnNotAvailableServlet</servlet-class>
>
>
<load-on-startup>1</load-on-startup>
You don't need to load this on startup if you don't want to: the
servlet will be initialized when necessary.
> </servlet>
>
> <servlet-mapping>
> <servlet-name>HttpResponseAdjuster</servlet-name>
> <url-pattern>/foo/*</url-pattern> </servlet-mapping>
>
> <servlet-mapping>
> <servlet-name>HttpResponseAdjuster</servlet-name>
> <url-pattern>/Testing/*</url-pattern> </servlet-mapping>
>
> Unfortunately, when I stop the "foo" context, tomcat is still
> returning the default HTTP 404 page. It doesn't appear to give any
> consideration to the servlet mapping in my ROOT context. Unless
> I've configured something wrong, it appears the desired behavior
> (to look for /Context first, then a ROOT servlet with mapping of
> /Context/*) isn't happening.
Yes, the longest match should win.
> You'll notice I setup another servlet-mapping called /Testing/*.
> "Testing" is NOT a context. When I go to myserver:8080/Testing my
> servlet handles the request and does what I desire (HTTP 503). To
> reiterate, my version of tomcat is 6.0.24. Perhaps the logic we're
> relying on wasn't introduced until later? Or maybe I'm missing a
> configuration option at a higher level to send failed requests to
> search the ROOT context for mappings?
Assuming you have everything configured as described, then your
expected behavior is also what I'd expect. Please test with latest
6.0 which is 6.0.35. If that doesn't work, please also test with
7.0.28 (freshly minted this weekend) and let us know if you have more
success.
If it does not work with 6.0.35 or it does not work with 7.0.28, can
you create a simple test case (ROOT.war + some other WAR w/overlapping
URI spaces) and create a Bugzilla ticket for it (or 2, if the bug
exists in both versions)?
- -chris
-----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/fyvkACgkQ9CaO5/Lv0PBkvwCgiZ9fDieTRdPSJTkrphxRn7Yi
CoUAoJy5RTwqSwSLCJe5hrnpmw747k4O
=5ESc
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Modify HTTP status returned by stopped context
Posted by kh...@oreillyauto.com.
Chris et. al.,
Thank you for the direction. I created my own servlet which loads without
error. Here is how I've configured it:
<servlet>
<servlet-name>HttpResponseAdjuster</servlet-name>
<servlet-class>bla.bla.tomcat.ReturnNotAvailableServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>HttpResponseAdjuster</servlet-name>
<url-pattern>/foo/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>HttpResponseAdjuster</servlet-name>
<url-pattern>/Testing/*</url-pattern>
</servlet-mapping>
Unfortunately, when I stop the "foo" context, tomcat is still returning the
default HTTP 404 page. It doesn't appear to give any consideration to the
servlet mapping in my ROOT context. Unless I've configured something
wrong, it appears the desired behavior (to look for /Context first, then a
ROOT servlet with mapping of /Context/*) isn't happening.
You'll notice I setup another servlet-mapping called /Testing/*. "Testing"
is NOT a context. When I go to myserver:8080/Testing my servlet handles
the request and does what I desire (HTTP 503). To reiterate, my version of
tomcat is 6.0.24. Perhaps the logic we're relying on wasn't introduced
until later? Or maybe I'm missing a configuration option at a higher level
to send failed requests to search the ROOT context for mappings?
I'm open to any ideas or alternate solutions at this point.
Thank you.
Kyle Harper
From: Christopher Schultz <ch...@christopherschultz.net>
To: Tomcat Users List <us...@tomcat.apache.org>
Date: 06/15/2012 05:05 PM
Subject: Re: Modify HTTP status returned by stopped context
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kyle,
On 6/15/12 12:30 PM, kharper2@oreillyauto.com wrote:
> I attempted to do what you prescribed but I am running into a snag
> and can't figure out what I've done incorrectly.
>
> I have a context, we'll call it /foo
>
> In my ROOT web application (/) I created a servlet with a mapping
> of /foo/* like so: <servlet>
> <servlet-name>foo-404-change</servlet-name>
>
>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
I
>
don't think you'll want to use the DefaultServlet for this purpose.
Try defining your own servlet that merely returns a 503 response. This
is better done as a servlet than a JSP, anyway.
> <servlet-mapping> <servlet-name>foo-404-change</servlet-name>
> <url-pattern>/foo/*</url-pattern> </servlet-mapping>
>
> I've created a simple JSP to respond with a 503. We'll call it
> change-status.jsp. If I call this page, it works fine. However,
> when I stop the context /foo, and attempt to reach /foo/whatever, I
> still get a 404 as if my servlet isn't even trying to handle the
> request.
>
> I thought maybe I needed to specify an error page so that ROOT
> would know what to do with a 404, so I setup the following in the
> ROOT web app's web.xml: <error-page> <error-code>404</error-code>
> <location>/change-status.jsp</location>
Don't map 404: just map /foo/* to your foo-404-change servlet and
leave it at that.
- -chris
-----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/bsAwACgkQ9CaO5/Lv0PAdOgCfdMi3jVdXL/mQ1qtBkZG9bSAt
TN0Ani5zPBO2eVCjHn+SGwbOBu93OXmP
=2vo8
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Modify HTTP status returned by stopped context
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kyle,
On 6/15/12 12:30 PM, kharper2@oreillyauto.com wrote:
> I attempted to do what you prescribed but I am running into a snag
> and can't figure out what I've done incorrectly.
>
> I have a context, we'll call it /foo
>
> In my ROOT web application (/) I created a servlet with a mapping
> of /foo/* like so: <servlet>
> <servlet-name>foo-404-change</servlet-name>
>
> <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
I
>
don't think you'll want to use the DefaultServlet for this purpose.
Try defining your own servlet that merely returns a 503 response. This
is better done as a servlet than a JSP, anyway.
> <servlet-mapping> <servlet-name>foo-404-change</servlet-name>
> <url-pattern>/foo/*</url-pattern> </servlet-mapping>
>
> I've created a simple JSP to respond with a 503. We'll call it
> change-status.jsp. If I call this page, it works fine. However,
> when I stop the context /foo, and attempt to reach /foo/whatever, I
> still get a 404 as if my servlet isn't even trying to handle the
> request.
>
> I thought maybe I needed to specify an error page so that ROOT
> would know what to do with a 404, so I setup the following in the
> ROOT web app's web.xml: <error-page> <error-code>404</error-code>
> <location>/change-status.jsp</location>
Don't map 404: just map /foo/* to your foo-404-change servlet and
leave it at that.
- -chris
-----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/bsAwACgkQ9CaO5/Lv0PAdOgCfdMi3jVdXL/mQ1qtBkZG9bSAt
TN0Ani5zPBO2eVCjHn+SGwbOBu93OXmP
=2vo8
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Modify HTTP status returned by stopped context
Posted by kh...@oreillyauto.com.
Mark,
I attempted to do what you prescribed but I am running into a snag and
can't figure out what I've done incorrectly.
I have a context, we'll call it /foo
In my ROOT web application (/) I created a servlet with a mapping of /foo/*
like so:
<servlet>
<servlet-name>foo-404-change</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>foo-404-change</servlet-name>
<url-pattern>/foo/*</url-pattern>
</servlet-mapping>
The above configuration loads fine (servlet starts up no problem).
I've created a simple JSP to respond with a 503. We'll call it
change-status.jsp. If I call this page, it works fine. However, when I
stop the context /foo, and attempt to reach /foo/whatever, I still get a
404 as if my servlet isn't even trying to handle the request.
I thought maybe I needed to specify an error page so that ROOT would know
what to do with a 404, so I setup the following in the ROOT web app's
web.xml:
<error-page>
<error-code>404</error-code>
<location>/change-status.jsp</location>
</error-page>
If I go to http://myserver:8080/not-a-real-page" the 404 triggers the
location specified, and my JSP correctly returns a blank page with an HTTP
status of 503.
If I go to http://myserver:8080/foo/not-a-real-page" while the context /foo
is running, I get a 404 as expected.
If I go to http://myserver:8080/foo/some-other-fake-page" while the
context /foo is stopped, I still just get a 404.
I'm not sure where to go from here, and would greatly appreciate any ideas
you (or anyone else) have.
Thanks,
Kyle Harper
From: Mark Thomas <ma...@apache.org>
To: Tomcat Users List <us...@tomcat.apache.org>
Date: 06/14/2012 03:19 PM
Subject: Re: Modify HTTP status returned by stopped context
On 14/06/2012 20:37, kharper2@oreillyauto.com wrote:
>
> Hello,
>
> I am running multiple web applications on a tomcat server. When a
request
> to a context in the stopped state is made, tomcat is returning 404 "not
> found" rather than 503 "unavailable". Is it possible to change this
> behavior in any way? Obviously I can't just modify _all_ HTTP 404
> responses to 503. Just those which are coming from a context in the
> stopped state.
Assume the context in question is /foo
In the ROOT web application add a servlet with a mapping of /foo/*
The servlet should just return a 503 (or any other error code)
This works because the mapping rules require the longest match to the
context be considered first. While /foo is running, requests will be
mapped to the /foo context and the servlet in the ROOT web application
is ignored. When /foo is not running, the request is mapped to the
servlet in the ROOT web app.
This obviously won't work for stopping the ROOT web app.
HTH,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Modify HTTP status returned by stopped context
Posted by Mark Thomas <ma...@apache.org>.
On 14/06/2012 20:37, kharper2@oreillyauto.com wrote:
>
> Hello,
>
> I am running multiple web applications on a tomcat server. When a request
> to a context in the stopped state is made, tomcat is returning 404 "not
> found" rather than 503 "unavailable". Is it possible to change this
> behavior in any way? Obviously I can't just modify _all_ HTTP 404
> responses to 503. Just those which are coming from a context in the
> stopped state.
Assume the context in question is /foo
In the ROOT web application add a servlet with a mapping of /foo/*
The servlet should just return a 503 (or any other error code)
This works because the mapping rules require the longest match to the
context be considered first. While /foo is running, requests will be
mapped to the /foo context and the servlet in the ROOT web application
is ignored. When /foo is not running, the request is mapped to the
servlet in the ROOT web app.
This obviously won't work for stopping the ROOT web app.
HTH,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org