You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Thomas Meyer <th...@m3y3r.de> on 2016/05/10 21:00:59 UTC
Question regarding parseRequestLine
Hi,
I noticed that I can block tomcat 8 by opening 200 connection to the
http 1.1 connector and send 512 bytes of zero in each connection.
Tomcat 8 seems to block in parseRequestLine() method for 20 seconds
(connectionTimeout) and times out after that.
The blocking seems to happen while waiting for the http method name.
I looked up RFC 2616 and byte zero is as far as I understand not a
legal character for the http method name which are GET, PUT and so on
and extension token which is defined as token which is defined as all
characters excluding 0-31 and 127.
So why doesn't tomcat trash the connection when it detects an invalid
http method name?
Is this behaviour just a super tolerant implementation?
Bug or feature? I'm curious to know the background of this
behaviour/implementation!
With kind regards
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Question regarding parseRequestLine
Posted by Mark Thomas <ma...@apache.org>.
On 12/05/2016 09:41, Mark Thomas wrote:
> On 10/05/2016 22:00, Thomas Meyer wrote:
>> Hi,
>>
>> I noticed that I can block tomcat 8 by opening 200 connection to the
>> http 1.1 connector and send 512 bytes of zero in each connection.
>>
>> Tomcat 8 seems to block in parseRequestLine() method for 20 seconds
>> (connectionTimeout) and times out after that.
>>
>> The blocking seems to happen while waiting for the http method name.
>
> Which connector are you using?
>
>> I looked up RFC 2616 and byte zero is as far as I understand not a
>> legal character for the http method name which are GET, PUT and so on
>> and extension token which is defined as token which is defined as all
>> characters excluding 0-31 and 127.
>> So why doesn't tomcat trash the connection when it detects an invalid
>> http method name?
>>
>> Is this behaviour just a super tolerant implementation?
>
> It looks like a very tolerant implementation.
>
>>
>> Bug or feature? I'm curious to know the background of this
>> behaviour/implementation!
>
> The background is it goes all the way back to 4.1.x. It may go back
> further but there was a big refactoring between 4.0.x and 4.1.x that was
> before my time so I never figured out my way around the 4.0.x code.
>
> Given that clients should not be sending non-token method values and
> such a value is probably indicative of an issue, detecting this and
> responding with a 400 is probably better than being tolerant. I'll take
> a look at a patch.
Fixed in call currently supported versions (6.0.x onwards) and will be
in the next release of each.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Question regarding parseRequestLine
Posted by Mark Thomas <ma...@apache.org>.
On 10/05/2016 22:00, Thomas Meyer wrote:
> Hi,
>
> I noticed that I can block tomcat 8 by opening 200 connection to the
> http 1.1 connector and send 512 bytes of zero in each connection.
>
> Tomcat 8 seems to block in parseRequestLine() method for 20 seconds
> (connectionTimeout) and times out after that.
>
> The blocking seems to happen while waiting for the http method name.
Which connector are you using?
> I looked up RFC 2616 and byte zero is as far as I understand not a
> legal character for the http method name which are GET, PUT and so on
> and extension token which is defined as token which is defined as all
> characters excluding 0-31 and 127.
> So why doesn't tomcat trash the connection when it detects an invalid
> http method name?
>
> Is this behaviour just a super tolerant implementation?
It looks like a very tolerant implementation.
>
> Bug or feature? I'm curious to know the background of this
> behaviour/implementation!
The background is it goes all the way back to 4.1.x. It may go back
further but there was a big refactoring between 4.0.x and 4.1.x that was
before my time so I never figured out my way around the 4.0.x code.
Given that clients should not be sending non-token method values and
such a value is probably indicative of an issue, detecting this and
responding with a 400 is probably better than being tolerant. I'll take
a look at a patch.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Question regarding parseRequestLine
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 10.05.2016 23:00, Thomas Meyer wrote:
> Hi,
>
> I noticed that I can block tomcat 8 by opening 200 connection to the
> http 1.1 connector and send 512 bytes of zero in each connection.
>
> Tomcat 8 seems to block in parseRequestLine() method for 20 seconds
> (connectionTimeout) and times out after that.
I do not know about the rest of your question.
But about the above, note that you can change this timeout (make it shorter), as indicated
here :
http://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Standard_Implementation
--> connectionTimeout
In current WWW circumstances, I cannot really think of any normal scenario in wich a
legitimate client would open a connection to a webserver, and then wait more than a couple
of seconds before sending a first valid request line.
>
> The blocking seems to happen while waiting for the http method name.
>
> I looked up RFC 2616 and byte zero is as far as I understand not a
> legal character for the http method name which are GET, PUT and so on
> and extension token which is defined as token which is defined as all
> characters excluding 0-31 and 127.
> So why doesn't tomcat trash the connection when it detects an invalid
> http method name?
>
> Is this behaviour just a super tolerant implementation?
>
> Bug or feature? I'm curious to know the background of this
> behaviour/implementation!
>
> With kind regards
> Thomas
>
> ---------------------------------------------------------------------
> 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