Bug 41179

Summary: 400 Bad Request response during auto re-deployment
Product: Tomcat 5 Reporter: Felix Gnass <felix.gnass>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: enhancement    
Priority: P5    
Version: 5.5.20   
Target Milestone: ---   
Hardware: PC   
OS: Linux   

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.