You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2011/01/25 17:48:32 UTC

400 error when a request does not map to a context

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

All,

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.

HTTP Spec says 400 means "The request could not be understood by the
server due to malformed syntax" but the request is perfectly valid.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0+/uAACgkQ9CaO5/Lv0PDTGgCdGsI9IKkZapKQarJQPlHMUp65
TlEAnRaRJwLLHnIfZwbn32W3p1/SgQAg
=h+lx
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


RE: 400 error when a request does not map to a context

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Pid [mailto:pid@pidster.com] 
> Subject: Re: 400 error when a request does not map to a context

> There was a list discussion about this recently, which I thought 
> led to a BZ, but I can't see it now.

You might be thinking of this one:
http://issues.apache.org/bugzilla/show_bug.cgi?id=49536

Symptoms were slightly different, and it was for Tomcat 7 only.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: 400 error when a request does not map to a context

Posted by Pid <pi...@pidster.com>.
On 1/25/11 5:37 PM, Michael Ludwig wrote:
> Christopher Schultz schrieb am 25.01.2011 um 11:48 (-0500):
>>
>> 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.
> 
> Definitely 404, as long as it isn't a "bad request".
> 
>> 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.
>>
>> HTTP Spec says 400 means "The request could not be understood by the
>> server due to malformed syntax" but the request is perfectly valid.

There was a list discussion about this recently, which I thought led to
a BZ, but I can't see it now.


p

Re: 400 error when a request does not map to a context

Posted by Michael Ludwig <mi...@gmx.de>.
Christopher Schultz schrieb am 25.01.2011 um 11:48 (-0500):
> 
> 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.

Definitely 404, as long as it isn't a "bad request".

> 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.
> 
> HTTP Spec says 400 means "The request could not be understood by the
> server due to malformed syntax" but the request is perfectly valid.

-- 
Michael Ludwig

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] 400 error when a request does not map to a context

Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/1/26 André Warnier <aw...@ice-sa.com>:
> By the way, having had my curiosity triggered by what Chris was reporting, I
> scanned the Servlet Spec 3.0 for mentions of the "ROOT" (default) context,
> and could not really find much of relevance.
> Namely, it does not mention that one is required.  Is it ?
> And it also does not mention webapps/ROOT as being a default context, or
> even as corresponding necessarily to the "top of the URL space".
> So, my question is : is "webapps/ROOT" purely a Tomcat thing, or did I miss
> something in the Servlet Spec ?
>

It is just the context that is mapped to path "". Naming it "ROOT" is
a Tomcat convention.

Technically, you can put <Context> element into server.xml and use any
name there.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: [OT] 400 error when a request does not map to a context

Posted by André Warnier <aw...@ice-sa.com>.
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.
> 
> Do you want to propose a patch? To return 404 instead of 400 when
> request cannot be matched.
> 
> 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).
> 
>> HTTP Spec says 400 means "The request could not be understood by the
>> server due to malformed syntax" but the request is perfectly valid.
> 

By the way, having had my curiosity triggered by what Chris was reporting, I scanned the 
Servlet Spec 3.0 for mentions of the "ROOT" (default) context, and could not really find 
much of relevance.
Namely, it does not mention that one is required.  Is it ?
And it also does not mention webapps/ROOT as being a default context, or even as 
corresponding necessarily to the "top of the URL space".
So, my question is : is "webapps/ROOT" purely a Tomcat thing, or did I miss something in 
the Servlet Spec ?



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: 400 error when a request does not map to a context

Posted by Pid * <pi...@pidster.com>.
On 26 Jan 2011, at 23:23, Christopher Schultz
<ch...@christopherschultz.net> wrote:

> -----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 :)

The last time this came up someone (Tim maybe?) suggested deploying a
default empty ROOT app, Thus enabling the valve chain.

p


>
> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: 400 error when a request does not map to a context

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: 400 error when a request does not map to a context

Posted by Konstantin Kolinko <kn...@gmail.com>.
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.

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

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).

> HTTP Spec says 400 means "The request could not be understood by the
> server due to malformed syntax" but the request is perfectly valid.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org