killbulle wrote:
Hi
i'am actually fighting with a modjk/tomcat 404 issue
if a webapps is stopped it returns a 404 not a 503 so i ihave to configure
404 as a KO error for the modjk
but 404 is a current code for some stupid css ressource or html page miss
so i ask myself why not a 503 web the webapps is stopped
I'll try and save someone else an explanation.
Part 1 :
Maybe first look at this first, because that is how HTTP is supposed to
work : http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
10.4.5 404 Not Found
10.5.4 503 Service Unavailable
The point is : the error code that you are seeing is not created by
mod_jk. It is the response from Tomcat, which mod_jk passes along.
Tomcat is a HTTP webserver, and the Tomcat (and mod_jk) developers try
to respect the official HTTP specifications, which are contained in the
above document.
Now sometimes, an error condition is such that it is not necessarily
clear which error code applies best to the situation. In that case, the
developers have to choose one, because they can only return one error code.
Part 2 :
Under Tomcat, each webapp has a path and a series of <url-pattern>
attributes (in web.xml). When a request is passed to Tomcat, it uses
those to select the webapp, and the servlet that will handle this
request. For this, Tomcat builds a table, on the base of the active
webapps.
Now if a request comes in, but there is not active webapp for that
path/url-pattern, what error code should Tomcat return ?
Presumably, if there was a webapp at that place, but you (the server
administrator) have turned it off, it is because you have decided to do
so, no ?
So it is not really a "server error", which the 5xx error codes are
supposed to represent.
When you turned off the webapp, Tomcat removed it from the table, so now
there is no longer any specific entry in the table for those URLs.
What probably happens, is that since there is no active webapp handling
this request anymore, Tomcat tries to serve the request by using the
default webapp and servlet. But the default webapp does not find this
resource, so it responds with a 404. Fair enough ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
