tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: 400 error when a request does not map to a context
Date Wed, 26 Jan 2011 23:22:31 GMT
Hash: SHA1


On 1/26/2011 10:55 AM, Konstantin Kolinko wrote:
> 2011/1/25 Christopher Schultz <>:
>> Should I expect that a request that doesn't map to a running context
>> should return a 400 error? I would have expected a 404 Not Found.
>> Tomcat 6.0.29 and Tomcat 7.0.6 both behave this way.
>> With no ROOT context deployed, make a request to something that doesn't
>> map to a deployed webapp, like "/nocontext" or even "/" and you'll get a
>> 400 Bad Request.
> It is a known issue, but I think that it is only of concern when the
> ROOT webapp is temporarily unavailable, e.g. being redeployed.
> In normal operation people do not see it.

My webapps are deployed into separate containers and so I usually don't
have a ROOT webapp deployed at all. Things usually go through mod_jk so
I don't see this kind of thing often but I was surprised to see a 400
response... at first I thought ff had gone braindead. :)

> Do you want to propose a patch? To return 404 instead of 400 when
> request cannot be matched.

That would be my proposal.

> 1) I think that it is somewhere around the Mapper class
> 2) I think that it is not possible to return well known green "page
> 404" html page (as valve is not available), but at least we can give
> blank response with correct HTTP result code (like Http11Processor and
> others do).

We have default error pages for things like 404, right? Why not use
those? Is it because without a context, the valve that usually handles
that stuff isn't available? Perhaps a valve chain could be built for
contextless requests or something like that. I'm sure that'll ruffle a
few feathers around here :)

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message