|Summary:||400 Bad Request response during auto re-deployment|
|Product:||Tomcat 5||Reporter:||Felix Gnass <felix.gnass>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
Description Felix Gnass 2006-12-15 05:45:34 UTC
When you re-deploy the root war file using autoDeploy="true", Tomcat sends a response with status code 400 (Bad Request: No host matches ...). This makes it impossible to serve a custom error document with Apache + mod_jk since the request processing is immediately halted to guard against security problems caused by bad requests. (See: http://httpd.apache.org/docs/2.0/mod/core.html#errordocument) RFC 2616 (section 10.4.1) says about status code 400: "The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications" The thing is, that there's nothing wrong with the client's request. It's not a syntactical issue and indeed the client SHOULD repeat the request. I wonder whether a 404, 500 or 503 wouldn't be more appropriate here, at least this would allow one to serve a custom error document during re-deployments.
Comment 1 Yoav Shapira 2007-03-25 15:21:04 UTC
I see what you mean, and it's indeed a PITA. The relevant code is in org.apache.catalina.core.StandardEngineValve#invoke(Request, Response). The problem is that this code is generic enough that you can't tell why request.getHost() returns null. It could be a normal webapp redeployment, or it could be an actual error. Thinking about, it seems like a 404 SC_NOT_FOUND is the better response here, since we couldn't find a virtual Host to service the request.
Comment 2 Remy Maucherat 2007-03-25 16:09:23 UTC
I used 400 for no particular reason. Using another status code could be better (or worse).
Comment 3 Mark Thomas 2011-07-22 22:51:22 UTC
This has already been fixed in 7.0.x and 6.0.x. I have proposed a back-port of the necessary changes for 5.5.x
Comment 4 Mark Thomas 2011-08-16 12:58:31 UTC
This has been fixed in trunk and will be in 5.5.34 onwards.