You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Michael Osipov <mi...@apache.org> on 2016/11/29 13:14:06 UTC
Validating HTTP status code
Hi folks,
while investigating another possible patch for the RewriteValve, I have
noticed that Tomcat 8.5 does not validate the set status code,
everything ist possible, e.g., -99 or 1000. Scanning the code I haven't
found any validation or such upto
org.apache.coyote.http11.Http11OutputBuffer.sendStatus().
RFC 7230, section 3.1.2 defines the EBNF the status-code is defined as
3DIGIT.
My question: is that an implementation error?
Not having checked Apache 2.4 yet, I know that mod_rewrite.c will return
an error if the status code is not between 100 and 900 [1].
Michael
[1]
https://github.com/apache/httpd/blob/fbc5e20ead005fd3a2bec05924f9e90dfd195406/modules/mappers/mod_rewrite.c#L3682-L3694
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Validating HTTP status code
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-11-29 um 15:40 schrieb Christopher Schultz:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Michael,
>
> On 11/29/16 8:14 AM, Michael Osipov wrote:
>> Hi folks,
>>
>> while investigating another possible patch for the RewriteValve, I
>> have noticed that Tomcat 8.5 does not validate the set status
>> code, everything ist possible, e.g., -99 or 1000. Scanning the code
>> I haven't found any validation or such upto
>> org.apache.coyote.http11.Http11OutputBuffer.sendStatus().
>>
>> RFC 7230, section 3.1.2 defines the EBNF the status-code is defined
>> as 3DIGIT.
>>
>> My question: is that an implementation error?
>>
>> Not having checked Apache 2.4 yet, I know that mod_rewrite.c will
>> return an error if the status code is not between 100 and 900 [1].
>
> I would say that in general validating the response code is probably
> not worth it. If an application wants to use customized response
> codes, they have plenty of codes already available but maybe they want
> to use a higher-numbered code.
>
> Are you suggesting that the behavior should be changed so that Tomcat
> can enforce the HTTP specification even when an application uses it in
> an out-of-spec way? Or were you thinking that there may be some deeper
> issue that Tomcat can help solve?
I do not have any problem at all, nor do I need to enforce any checks. I
wanted to clarify the current status.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Validating HTTP status code
Posted by Mark Thomas <ma...@apache.org>.
On 29/11/2016 18:18, Michael Osipov wrote:
> Am 2016-11-29 um 16:07 schrieb Mark Thomas:
>> On 29/11/2016 14:40, Christopher Schultz wrote:
>>> Michael,
>>>
>>> On 11/29/16 8:14 AM, Michael Osipov wrote:
>>>> Hi folks,
>>>
>>>> while investigating another possible patch for the RewriteValve, I
>>>> have noticed that Tomcat 8.5 does not validate the set status
>>>> code, everything ist possible, e.g., -99 or 1000. Scanning the code
>>>> I haven't found any validation or such upto
>>>> org.apache.coyote.http11.Http11OutputBuffer.sendStatus().
>>>
>>>> RFC 7230, section 3.1.2 defines the EBNF the status-code is defined
>>>> as 3DIGIT.
>>>
>>>> My question: is that an implementation error?
>>>
>>>> Not having checked Apache 2.4 yet, I know that mod_rewrite.c will
>>>> return an error if the status code is not between 100 and 900 [1].
>>>
>>> I would say that in general validating the response code is probably
>>> not worth it. If an application wants to use customized response
>>> codes, they have plenty of codes already available but maybe they want
>>> to use a higher-numbered code.
>>>
>>> Are you suggesting that the behavior should be changed so that Tomcat
>>> can enforce the HTTP specification even when an application uses it in
>>> an out-of-spec way? Or were you thinking that there may be some deeper
>>> issue that Tomcat can help solve?
>>>
>>> Validating the response code would only take a little bit of time, and
>>> usually response codes aren't set many times per request, so the
>>> overhead would probably be minimal.
>>
>> If it is validated at all for the RewriteValve, I'd do it once during
>> init rather than per request.
>
> This is what I was about to do. My primary goal was to complete the
> redirect rule where mod_rewrite.c rejects codes below 100 and 900 and
> stops processing immediately if the code is not one of 3xx.
>
> Is that desired or do you want to leave it that way?
It isn't an itch I want to scratch but if it can be implemented with a
reasonable patch I'm happy to review that patch.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Validating HTTP status code
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-11-29 um 16:07 schrieb Mark Thomas:
> On 29/11/2016 14:40, Christopher Schultz wrote:
>> Michael,
>>
>> On 11/29/16 8:14 AM, Michael Osipov wrote:
>>> Hi folks,
>>
>>> while investigating another possible patch for the RewriteValve, I
>>> have noticed that Tomcat 8.5 does not validate the set status
>>> code, everything ist possible, e.g., -99 or 1000. Scanning the code
>>> I haven't found any validation or such upto
>>> org.apache.coyote.http11.Http11OutputBuffer.sendStatus().
>>
>>> RFC 7230, section 3.1.2 defines the EBNF the status-code is defined
>>> as 3DIGIT.
>>
>>> My question: is that an implementation error?
>>
>>> Not having checked Apache 2.4 yet, I know that mod_rewrite.c will
>>> return an error if the status code is not between 100 and 900 [1].
>>
>> I would say that in general validating the response code is probably
>> not worth it. If an application wants to use customized response
>> codes, they have plenty of codes already available but maybe they want
>> to use a higher-numbered code.
>>
>> Are you suggesting that the behavior should be changed so that Tomcat
>> can enforce the HTTP specification even when an application uses it in
>> an out-of-spec way? Or were you thinking that there may be some deeper
>> issue that Tomcat can help solve?
>>
>> Validating the response code would only take a little bit of time, and
>> usually response codes aren't set many times per request, so the
>> overhead would probably be minimal.
>
> If it is validated at all for the RewriteValve, I'd do it once during
> init rather than per request.
This is what I was about to do. My primary goal was to complete the
redirect rule where mod_rewrite.c rejects codes below 100 and 900 and
stops processing immediately if the code is not one of 3xx.
Is that desired or do you want to leave it that way?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Validating HTTP status code
Posted by Mark Thomas <ma...@apache.org>.
On 29/11/2016 14:40, Christopher Schultz wrote:
> Michael,
>
> On 11/29/16 8:14 AM, Michael Osipov wrote:
>> Hi folks,
>
>> while investigating another possible patch for the RewriteValve, I
>> have noticed that Tomcat 8.5 does not validate the set status
>> code, everything ist possible, e.g., -99 or 1000. Scanning the code
>> I haven't found any validation or such upto
>> org.apache.coyote.http11.Http11OutputBuffer.sendStatus().
>
>> RFC 7230, section 3.1.2 defines the EBNF the status-code is defined
>> as 3DIGIT.
>
>> My question: is that an implementation error?
>
>> Not having checked Apache 2.4 yet, I know that mod_rewrite.c will
>> return an error if the status code is not between 100 and 900 [1].
>
> I would say that in general validating the response code is probably
> not worth it. If an application wants to use customized response
> codes, they have plenty of codes already available but maybe they want
> to use a higher-numbered code.
>
> Are you suggesting that the behavior should be changed so that Tomcat
> can enforce the HTTP specification even when an application uses it in
> an out-of-spec way? Or were you thinking that there may be some deeper
> issue that Tomcat can help solve?
>
> Validating the response code would only take a little bit of time, and
> usually response codes aren't set many times per request, so the
> overhead would probably be minimal.
If it is validated at all for the RewriteValve, I'd do it once during
init rather than per request.
Tomcat doesn't currently validate the status code at all if an
application calls setStatus(). One problem with adding validation is
that the spec doesn't define any exceptions for setStatus() and friends.
You'd need to use an unchecked exception, ignore the call or use some
default code. None of which is particularly nice.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Validating HTTP status code
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Michael,
On 11/29/16 8:14 AM, Michael Osipov wrote:
> Hi folks,
>
> while investigating another possible patch for the RewriteValve, I
> have noticed that Tomcat 8.5 does not validate the set status
> code, everything ist possible, e.g., -99 or 1000. Scanning the code
> I haven't found any validation or such upto
> org.apache.coyote.http11.Http11OutputBuffer.sendStatus().
>
> RFC 7230, section 3.1.2 defines the EBNF the status-code is defined
> as 3DIGIT.
>
> My question: is that an implementation error?
>
> Not having checked Apache 2.4 yet, I know that mod_rewrite.c will
> return an error if the status code is not between 100 and 900 [1].
I would say that in general validating the response code is probably
not worth it. If an application wants to use customized response
codes, they have plenty of codes already available but maybe they want
to use a higher-numbered code.
Are you suggesting that the behavior should be changed so that Tomcat
can enforce the HTTP specification even when an application uses it in
an out-of-spec way? Or were you thinking that there may be some deeper
issue that Tomcat can help solve?
Validating the response code would only take a little bit of time, and
usually response codes aren't set many times per request, so the
overhead would probably be minimal.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJYPZNKAAoJEBzwKT+lPKRY2UYQAL5c9LWaeQUWbO6yBy3Dmlds
Z7qhbH+sqClPoerKKEKY536UvWaos5A465eJNv1kEDDGZ5x+ukN05Vc9ZXdMLD3u
JrftsNP+vDH88WATbrncZ5pxyFEnoPSuG2YknYO1xyqE8EOzMJV5X7LFM2gU5ElI
Iqxn0CQ+MPTLA7+CbZ7GmZbfYGU4FXsJEO5UWXHYQDJiP5+W6xb35fXU6kQ+iicq
QSRIYnt6pICS8m0KPwFQfc6d5VlTzx8bGi/YYe2FGlmL/9hQv+WpAhhJpyMXTCCx
J8jgECDJFctf8YuomFrpY3TCh6FcBH+wk2f6+VDRLnYp+Zzy5fj5fRWT4+7nPLuJ
oNBUV2BuSjqITBzITEFyDb1aUktO8tR9aqt+AJ8TqjBKuo5foxJvIQ/rIs/8AIpg
YSMvn/wj0VaMxVxAxuUzbYPaPks58X3VAwbQ/qBQ8RUl18F/FE2NEq3Kr1MCFSqg
XFnoNawvR5KfQOX2kduYezE62mNvDF5V3S771CFmQ7zs68FMmgRAB9A5gVoAx4td
X9Mz+pkBXBH85mEq777XB+ZAQ0gFavbpjSyDd1mce3tDxo+Ys0tGeocGoq8GR27w
2qdMtxlvgCSyjOKyDheO8M6RUEE4mLf9tTIeNVD6SpGDgWsJM2KwnGf9i+GoXq50
qMYZP6om7iKANJukxbcn
=fvBq
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org