-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Konstantin,
On 1/26/2011 10:55 AM, Konstantin Kolinko wrote: > 2011/1/25 Christopher Schultz <ch...@christopherschultz.net>: >> 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 :) Thanks, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1ArLcACgkQ9CaO5/Lv0PBDuACgvZ/IrwM9RLaIjaTdXDjqKDxP oIsAnReNCVk+jLW7h360KlkM89bDF56b =icka -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
