You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Olaf Tomczak <ol...@gmail.com> on 2010/12/27 18:59:20 UTC
Http11NioProtocol error 505 (or 400)
Hi,
I'm using Http11NioProtocol connector on my Tomcat 6.0.29 instance and I
noticed that sometimes I experience strange responses:
- 400 - Bad Request,
- 505 - HTTP Version Not Supported
My first conclusion was that it's somewhat related to the size of the
request (e.g. clearing session cookies always fixed the problem). I then
recompiled Tomcat from sources adding some additional logs
to Http11NioProcessor and InternalNioInputBuffer classes. I also isolated a
test request that always fails on my test server instace and used it as a
JMeter test configuration.
I'm using the following connector configuration:
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxThreads="256" minSpareThreads="32"/>
<Connector executor="tomcatThreadPool"
acceptorThreadCount="4"
useComet="false"
address="0.0.0.0"
port="4080"
protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="30000"
redirectPort="4443"
enableLookups="false"
/>
Looking at my logs I found out that the request fails with the following
scenario:
InternalNioInputBuffer.parseRequestLine - successfully parses the first
request line
InternalNioInputBuffer.parseHeader - parses some headers but then fails to
read more data and returns with HeaderParseStatus.NEED_MORE_DATA status
InternalNioInputBuffer.parseRequestLine - is called again and then tries to
parse the remaining headers and fails with 505 since it takes a part of
'User-Agent' header value as a protocol name.
Can someone familiar with the Http11NioProtocol connector help me with this
problem?
I also noticed that when a use a local instance of Tomcat (on the same host
as my jmeter) with the same configuration the requests work (I suppose it's
because the connection is faster and more data is available in the buffer
without delay).
Thanks a lot,
Olaf Tomczak
Re: Http11NioProtocol error 505 (or 400)
Posted by Olaf Tomczak <ol...@gmail.com>.
2010/12/27 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Olaf,
>
> On 12/27/2010 12:59 PM, Olaf Tomczak wrote:
> > I also isolated a
> > test request that always fails on my test server instace and used it as a
> > JMeter test configuration.
>
> Excellent. Can you post that rest request to the list?
>
I'll make sure to do that tommorow.
>
> > InternalNioInputBuffer.parseRequestLine - successfully parses the first
> > request line
> > InternalNioInputBuffer.parseHeader - parses some headers but then fails
> to
> > read more data and returns with HeaderParseStatus.NEED_MORE_DATA status
> > InternalNioInputBuffer.parseRequestLine - is called again and then tries
> to
> > parse the remaining headers and fails with 505 since it takes a part of
> > 'User-Agent' header value as a protocol name.
>
> I notice that you didn't have a maxHttpHeaderSize attribute on your
> connector. Is it possible that you have a header section that is too large?
>
My request was under 1500 bytes so this is probably not the case, I'll check
that anyway.
>
> > I also noticed that when a use a local instance of Tomcat (on the same
> host
> > as my jmeter) with the same configuration the requests work (I suppose
> it's
> > because the connection is faster and more data is available in the buffer
> > without delay).
>
> Probably not. It is possible that "localhost" is a shorter hostname than
> your remote clients and that the request headers end up being short
> enough just due to that.
>
Well I tried to add additional characters to the query string to compensate
that.. You may be right however.. didn't have much time to test it. Still I
don't understand why this HeaderParseStatus.NEED_MORE_DATA status is
generally never handled..
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0ZA7oACgkQ9CaO5/Lv0PAyNQCcD/aIYp+lzTqAf2NvyUEvKp9+
> bKoAoMGDToR4vUZowxFRjreu9k8ie10D
> =EY8I
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Http11NioProtocol error 505 (or 400)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Olaf,
On 12/27/2010 12:59 PM, Olaf Tomczak wrote:
> I also isolated a
> test request that always fails on my test server instace and used it as a
> JMeter test configuration.
Excellent. Can you post that rest request to the list?
> InternalNioInputBuffer.parseRequestLine - successfully parses the first
> request line
> InternalNioInputBuffer.parseHeader - parses some headers but then fails to
> read more data and returns with HeaderParseStatus.NEED_MORE_DATA status
> InternalNioInputBuffer.parseRequestLine - is called again and then tries to
> parse the remaining headers and fails with 505 since it takes a part of
> 'User-Agent' header value as a protocol name.
I notice that you didn't have a maxHttpHeaderSize attribute on your
connector. Is it possible that you have a header section that is too large?
> I also noticed that when a use a local instance of Tomcat (on the same host
> as my jmeter) with the same configuration the requests work (I suppose it's
> because the connection is faster and more data is available in the buffer
> without delay).
Probably not. It is possible that "localhost" is a shorter hostname than
your remote clients and that the request headers end up being short
enough just due to that.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0ZA7oACgkQ9CaO5/Lv0PAyNQCcD/aIYp+lzTqAf2NvyUEvKp9+
bKoAoMGDToR4vUZowxFRjreu9k8ie10D
=EY8I
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Http11NioProtocol error 505 (or 400)
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
...
>
>> I would thus imagine that the Tomcat developers in their wisdom seeked
>> to prevent this
>
> (NB for non-native English speakers: "seeked" is an incorrect past
> imperfect conjugation of "seek". The proper past imperfect conjugation
> is "sought". I know, right?)
>
Thanks. I sought it was ze right vörd, because "the disk-head sought the cylinder" sounds
strange.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Http11NioProtocol error 505 (or 400)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 12/28/2010 5:11 AM, André Warnier wrote:
> Business is slow these days, so let's muse a bit.
One of my favorite bands.
> There is no mention of a size limit for the headers part, nor any
> mention of any special ordering of the individual headers.
Yup.
> In other words, as far as the RFC is concerned, there could be a million
> header lines, and the "Host:" header could be the last one of them.
> (Except for a confusing example in section 5.1.2, but then, such things
> happen in RFCs).
Yup.
> In other words also, if Tomcat started to parse the request headers
> before it is sure to have all of them, it would have to store the
> results of such parsing in some temporary holding area, because at that
> point it may not have seen the "Host:" header yet, and thus not know
> which <Host> is supposed to handle this request (among other things).
> And this would offer a major opening for anyone wanting to mount a DOS
> attack : just send a few requests with very, very large header sections,
> to overwhelm this temporary holding area.
Agreed. The maxHttpHeaderSize setting is designed just for this
situation: Tomcat must buffer this information somehow, and the buffer
must be limited otherwise servers can be taken down.
This is a practical implementation detail that is not covered in the RFC
because it's just that: an implementation detail, which has no business
being in an RFC.
> I would thus imagine that the Tomcat developers in their wisdom seeked
> to prevent this
(NB for non-native English speakers: "seeked" is an incorrect past
imperfect conjugation of "seek". The proper past imperfect conjugation
is "sought". I know, right?)
> by implementing a limit to how large a HTTP headers
> section would be reasonably expected to be. And let's say that this is
> the maxHttpHeaderSize attribute, and that by default it is set to about
> 8KB.
> So the logic of reading the request reads it, up to either two
> consecutive CR/LF indicating the end of the headers, /or/ a limit of
> maxHttpHeaderSize bytes, and then declares that it has all the headers
> and attempts to parse them.
No, Tomcat should fail if the request line + headers (or maybe just the
headers after the request line?) exceed maxHttpHeaderSize. Otherwise, an
incomplete request might be processed incorrectly.
> That's the price to pay for avoiding the DOS attack.
Or even a resource exhaustion during normal operations.
> Now the optional /body/ of the request is something else, because by
> then Tomcat already knows which Host and which webapp should handle it,
> what format it is supposed to be in etc.., and can feed it to this
> webapp one chunk at a time, with or without blocking a Connector for the
> purpose.
Yup, and it's the webapp's responsibility to determine how to read the
request, buffer it, etc.: the container merely provides the API to read
the bytes.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0aoo8ACgkQ9CaO5/Lv0PAXbACfUZITh+Z+sfjXPCSSzlwyF97u
HTIAoJ3a7+ZVeCfncbKHOPtQ/XXenZ9E
=rpI5
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Http11NioProtocol error 505 (or 400)
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Olaf,
>
> On 12/27/2010 5:24 PM, Olaf Tomczak wrote:
>> 2010/12/27 Christopher Schultz <ch...@christopherschultz.net>
>>> Non-blocking just means that your request processor threads don't block
>>> waiting for data to arrive. The requirements of reading the request --
>>> including all the headers -- do not change with the connector. Tomcat
>>> needs to read the entire set of headers in order to route the request to
>>> the right host and webapp. Also, Tomcat must have all headers in order
>>> to perform some operations -- such as responding to "getHeaders" calls
>>> which sometimes require that multiple separate HTTP header lines be
>>> merged into a single method return value.
>> I understand that the whole request must be read to start "request
>> processing" - I was just suggesting that from what I understand the
>> connector does not wait for the buffer to be completely filled before
>> starting to parse request line and headers. Isn't that right?
>
> I don't believe the difference you describe would be detectable at any
> level. The choice of connector does not change the logic for request
> processing: only that of gathering the bytes from the request.
>
Business is slow these days, so let's muse a bit.
Tomcat is a HTTP server, and processes HTTP requests (a sub-category of HTTP Messages), as
defined in RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html).
Section 4 defines precisely what a message is, so I will not repeat it here.
But the essence is that there is a start-line, followed by a series of optional headers
lines, followed by one empty line (2 CR/LF in a row), sometimes followed by a body
(depends on request type).
There is no mention of a size limit for the headers part, nor any mention of any special
ordering of the individual headers.
In other words, as far as the RFC is concerned, there could be a million header lines, and
the "Host:" header could be the last one of them. (Except for a confusing example in
section 5.1.2, but then, such things happen in RFCs).
In other words also, if Tomcat started to parse the request headers before it is sure to
have all of them, it would have to store the results of such parsing in some temporary
holding area, because at that point it may not have seen the "Host:" header yet, and thus
not know which <Host> is supposed to handle this request (among other things).
And this would offer a major opening for anyone wanting to mount a DOS attack : just send
a few requests with very, very large header sections, to overwhelm this temporary holding
area.
I would thus imagine that the Tomcat developers in their wisdom seeked to prevent this, by
implementing a limit to how large a HTTP headers section would be reasonably expected to
be. And let's say that this is the maxHttpHeaderSize attribute, and that by default it is
set to about 8KB.
So the logic of reading the request reads it, up to either two consecutive CR/LF
indicating the end of the headers, /or/ a limit of maxHttpHeaderSize bytes, and then
declares that it has all the headers and attempts to parse them.
And if it so happens that the request would contain a larger header section, tough.
That's the price to pay for avoiding the DOS attack.
Now the optional /body/ of the request is something else, because by then Tomcat already
knows which Host and which webapp should handle it, what format it is supposed to be in
etc.., and can feed it to this webapp one chunk at a time, with or without blocking a
Connector for the purpose.
The above is purely speculative, as I have not looked at the actual code to verify that it
is so. But this being rather central to what Tomcat is and does, I could imagine that by
the time one is able to confirm or deny this, he may well have read a good portion of the
Tomcat code.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
+1 for 6.0.30 (was: Re: Http11NioProtocol error 505 (or 400))
Posted by Ronald Klop <ro...@base.nl>.
Hi,
May I vote +1 for a 6.0.30 in relation to this bug.
Ronald.
Op dinsdag, 28 december 2010 10:19 schreef Olaf Tomczak <ol...@gmail.com>:
>
>
>
>
> Ok,
>
> I used Mark Thomas' patch that Roland suggested - created a clean instance of Tomcat with and without the patch and tested it with my request. Indeed the patched instance handles the requests correctly. Just FYI this is my request:
>
> GET /0123456789012345678901234567890123456.htm HTTP/1.1
> Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3
> Accept-Encoding: gzip,deflate,sdch
> Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4
> Authorization: Basic 012345678901234567890123
> Cache-Control: max-age=0
> Cookie: test_cookie=0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
> Referer: http://example.org/012345678912345678901234567890123456789012345678901
> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Sabayon Chrome/8.0.552.210 Safari/534.10
> Host: olaftomczak.com:6060
> Connection: keep-alive
>
> I also attached it as a JMeter test configuration.
> Here're the results:
> - patched instance:
> <sampleResult responseMessage="Not Found" responseCode="404" dataType="text" time="245" timeStamp="1293527375642" threadName="Thread Group1-1" label="HTTP Request" success="false"/>
> - instance with no patch:
> <sampleResult responseMessage="HTTP Version Not Supported" responseCode="505" dataType="" time="444" timeStamp="1293527344000" threadName="Thread Group1-1" label="HTTP Request" success="false"/>
>
> Thanks for your help guys!
>
> Cheers, Olaf
>
>
> 2010/12/28 Christopher Schultz <ch...@christopherschultz.net>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Olaf,
>>
>> On 12/27/2010 5:24 PM, Olaf Tomczak wrote:
>> > 2010/12/27 Christopher Schultz <ch...@christopherschultz.net>
>> >> Non-blocking just means that your request processor threads don't block
>> >> waiting for data to arrive. The requirements of reading the request --
>> >> including all the headers -- do not change with the connector. Tomcat
>> >> needs to read the entire set of headers in order to route the request to
>> >> the right host and webapp. Also, Tomcat must have all headers in order
>> >> to perform some operations -- such as responding to "getHeaders" calls
>> >> which sometimes require that multiple separate HTTP header lines be
>> >> merged into a single method return value.
>> >
>> > I understand that the whole request must be read to start "request
>> > processing" - I was just suggesting that from what I understand the
>> > connector does not wait for the buffer to be completely filled before
>> > starting to parse request line and headers. Isn't that right?
>>
>> I don't believe the difference you describe would be detectable at any
>> level. The choice of connector does not change the logic for request
>> processing: only that of gathering the bytes from the request.
>>
>>
>> - -chris
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk0ZGxMACgkQ9CaO5/Lv0PCygACgv66l6yc6Wubf/szFbfgOm90B
>> nEgAoI/MAXqpieNtwKr3p389EV6lyQy5
>> =MsJZ
>>
>>
>> -----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: Http11NioProtocol error 505 (or 400)
Posted by Olaf Tomczak <ol...@gmail.com>.
Ok,
I used Mark Thomas' patch that Roland suggested - created a clean instance
of Tomcat with and without the patch and tested it with my request. Indeed
the patched instance handles the requests correctly. Just FYI this is my
request:
GET /0123456789012345678901234567890123456.htm HTTP/1.1
Accept:
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3
Accept-Encoding: gzip,deflate,sdch
Accept-Language: pl-PL,pl;q=0.8,en-US;q=0.6,en;q=0.4
Authorization: Basic 012345678901234567890123
Cache-Control: max-age=0
Cookie:
test_cookie=0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
Referer:
http://example.org/012345678912345678901234567890123456789012345678901
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.10
(KHTML, like Gecko) Sabayon Chrome/8.0.552.210 Safari/534.10
Host: olaftomczak.com:6060
Connection: keep-alive
I also attached it as a JMeter test configuration.
Here're the results:
- patched instance:
<sampleResult responseMessage="Not Found" responseCode="404" dataType="text"
time="245" timeStamp="1293527375642" threadName="Thread Group1-1"
label="HTTP Request" success="false"/>
- instance with no patch:
<sampleResult responseMessage="HTTP Version Not Supported"
responseCode="505" dataType="" time="444" timeStamp="1293527344000"
threadName="Thread Group1-1" label="HTTP Request" success="false"/>
Thanks for your help guys!
Cheers, Olaf
2010/12/28 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Olaf,
>
> On 12/27/2010 5:24 PM, Olaf Tomczak wrote:
> > 2010/12/27 Christopher Schultz <ch...@christopherschultz.net>
> >> Non-blocking just means that your request processor threads don't block
> >> waiting for data to arrive. The requirements of reading the request --
> >> including all the headers -- do not change with the connector. Tomcat
> >> needs to read the entire set of headers in order to route the request to
> >> the right host and webapp. Also, Tomcat must have all headers in order
> >> to perform some operations -- such as responding to "getHeaders" calls
> >> which sometimes require that multiple separate HTTP header lines be
> >> merged into a single method return value.
> >
> > I understand that the whole request must be read to start "request
> > processing" - I was just suggesting that from what I understand the
> > connector does not wait for the buffer to be completely filled before
> > starting to parse request line and headers. Isn't that right?
>
> I don't believe the difference you describe would be detectable at any
> level. The choice of connector does not change the logic for request
> processing: only that of gathering the bytes from the request.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0ZGxMACgkQ9CaO5/Lv0PCygACgv66l6yc6Wubf/szFbfgOm90B
> nEgAoI/MAXqpieNtwKr3p389EV6lyQy5
> =MsJZ
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Http11NioProtocol error 505 (or 400)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Olaf,
On 12/27/2010 5:24 PM, Olaf Tomczak wrote:
> 2010/12/27 Christopher Schultz <ch...@christopherschultz.net>
>> Non-blocking just means that your request processor threads don't block
>> waiting for data to arrive. The requirements of reading the request --
>> including all the headers -- do not change with the connector. Tomcat
>> needs to read the entire set of headers in order to route the request to
>> the right host and webapp. Also, Tomcat must have all headers in order
>> to perform some operations -- such as responding to "getHeaders" calls
>> which sometimes require that multiple separate HTTP header lines be
>> merged into a single method return value.
>
> I understand that the whole request must be read to start "request
> processing" - I was just suggesting that from what I understand the
> connector does not wait for the buffer to be completely filled before
> starting to parse request line and headers. Isn't that right?
I don't believe the difference you describe would be detectable at any
level. The choice of connector does not change the logic for request
processing: only that of gathering the bytes from the request.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0ZGxMACgkQ9CaO5/Lv0PCygACgv66l6yc6Wubf/szFbfgOm90B
nEgAoI/MAXqpieNtwKr3p389EV6lyQy5
=MsJZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Http11NioProtocol error 505 (or 400)
Posted by Olaf Tomczak <ol...@gmail.com>.
Chris,
2010/12/27 Christopher Schultz <ch...@christopherschultz.net>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Olaf,
>
> On 12/27/2010 5:02 PM, Olaf Tomczak wrote:
> > 2010/12/27 André Warnier <aw...@ice-sa.com>
> >> I believe that in the default configuration, Tomcat expects to read the
> >> request line *and all the headers* in the first read of maximum 8000
> bytes.
> >> The cookies are part of the headers.
> >>
> >> Increase the maxHttpHeaderSize attribute to cover the headers of the
> >> largest likely request and see what happens ?
> >
> > I did not increase this attribute, although I don't think my request was
> > larger than 1500 bytes.
>
> Please check. Can you post your test case?
>
> > Besides I thought that the whole idea of non-blocking connector is
> > that it doesn't have to read the whole request at once - isn't that
> > what blocking connector does?
>
> Non-blocking just means that your request processor threads don't block
> waiting for data to arrive. The requirements of reading the request --
> including all the headers -- do not change with the connector. Tomcat
> needs to read the entire set of headers in order to route the request to
> the right host and webapp. Also, Tomcat must have all headers in order
> to perform some operations -- such as responding to "getHeaders" calls
> which sometimes require that multiple separate HTTP header lines be
> merged into a single method return value.
>
I understand that the whole request must be read to start "request
processing" - I was just suggesting that from what I understand the
connector does not wait for the buffer to be completely filled before
starting to parse request line and headers. Isn't that right?
Thanks, Olaf
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk0ZD3AACgkQ9CaO5/Lv0PCqXwCfbuybnLIOtiTLO72/e2OBSkKo
> RFwAoIVXMaXHIrTuVMxoAYpJIsykP8er
> =z0Hx
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Http11NioProtocol error 505 (or 400)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Olaf,
On 12/27/2010 5:02 PM, Olaf Tomczak wrote:
> 2010/12/27 André Warnier <aw...@ice-sa.com>
>> I believe that in the default configuration, Tomcat expects to read the
>> request line *and all the headers* in the first read of maximum 8000 bytes.
>> The cookies are part of the headers.
>>
>> Increase the maxHttpHeaderSize attribute to cover the headers of the
>> largest likely request and see what happens ?
>
> I did not increase this attribute, although I don't think my request was
> larger than 1500 bytes.
Please check. Can you post your test case?
> Besides I thought that the whole idea of non-blocking connector is
> that it doesn't have to read the whole request at once - isn't that
> what blocking connector does?
Non-blocking just means that your request processor threads don't block
waiting for data to arrive. The requirements of reading the request --
including all the headers -- do not change with the connector. Tomcat
needs to read the entire set of headers in order to route the request to
the right host and webapp. Also, Tomcat must have all headers in order
to perform some operations -- such as responding to "getHeaders" calls
which sometimes require that multiple separate HTTP header lines be
merged into a single method return value.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk0ZD3AACgkQ9CaO5/Lv0PCqXwCfbuybnLIOtiTLO72/e2OBSkKo
RFwAoIVXMaXHIrTuVMxoAYpJIsykP8er
=z0Hx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Http11NioProtocol error 505 (or 400)
Posted by Olaf Tomczak <ol...@gmail.com>.
Thanks guys,
2010/12/27 André Warnier <aw...@ice-sa.com>
> Ronald Klop wrote:
>
>>
>> I see similar errors. If it is the same there should be a fix in Tomcat
>> 7.0.4 and 6.0.30 (not released yet)
>>
>> Something like this?
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=50072
>>
>
>
This sure looks similar.. I'll try the patch tomorrow
> Or look for an earlier thread on this list, started on 13.12.2010, subject
> :
> Is there an upload limit of around 8000 bytes in tomcat 6?
>
> That matches what Christopher just mentioned.
>
> I believe that in the default configuration, Tomcat expects to read the
> request line *and all the headers* in the first read of maximum 8000 bytes.
> The cookies are part of the headers.
>
> Increase the maxHttpHeaderSize attribute to cover the headers of the
> largest likely request and see what happens ?
>
>
> I did not increase this attribute, although I don't think my request was
larger than 1500 bytes. Besides I thought that the whole idea of
non-blocking connector is that it doesn't have to read the whole request at
once - isn't that what blocking connector does?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Http11NioProtocol error 505 (or 400)
Posted by André Warnier <aw...@ice-sa.com>.
Ronald Klop wrote:
>
> I see similar errors. If it is the same there should be a fix in Tomcat
> 7.0.4 and 6.0.30 (not released yet)
>
> Something like this?
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50072
Or look for an earlier thread on this list, started on 13.12.2010, subject :
Is there an upload limit of around 8000 bytes in tomcat 6?
That matches what Christopher just mentioned.
I believe that in the default configuration, Tomcat expects to read the request line *and
all the headers* in the first read of maximum 8000 bytes.
The cookies are part of the headers.
Increase the maxHttpHeaderSize attribute to cover the headers of the largest likely
request and see what happens ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Http11NioProtocol error 505 (or 400)
Posted by Ronald Klop <ro...@base.nl>.
I see similar errors. If it is the same there should be a fix in Tomcat 7.0.4 and 6.0.30 (not released yet)
Something like this?
https://issues.apache.org/bugzilla/show_bug.cgi?id=50072
Ronald.
Op maandag, 27 december 2010 18:59 schreef Olaf Tomczak <ol...@gmail.com>:
>
> Hi,
>
> I'm using Http11NioProtocol connector on my Tomcat 6.0.29 instance and I
> noticed that sometimes I experience strange responses:
> - 400 - Bad Request,
> - 505 - HTTP Version Not Supported
>
> My first conclusion was that it's somewhat related to the size of the
> request (e.g. clearing session cookies always fixed the problem). I then
> recompiled Tomcat from sources adding some additional logs
> to Http11NioProcessor and InternalNioInputBuffer classes. I also isolated a
> test request that always fails on my test server instace and used it as a
> JMeter test configuration.
>
> I'm using the following connector configuration:
>
> <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
> maxThreads="256" minSpareThreads="32"/>
> <Connector executor="tomcatThreadPool"
> acceptorThreadCount="4"
> useComet="false"
> address="0.0.0.0"
> port="4080"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> connectionTimeout="30000"
> redirectPort="4443"
> enableLookups="false"
> />
>
> Looking at my logs I found out that the request fails with the following
> scenario:
>
> InternalNioInputBuffer.parseRequestLine - successfully parses the first
> request line
> InternalNioInputBuffer.parseHeader - parses some headers but then fails to
> read more data and returns with HeaderParseStatus.NEED_MORE_DATA status
> InternalNioInputBuffer.parseRequestLine - is called again and then tries to
> parse the remaining headers and fails with 505 since it takes a part of
> 'User-Agent' header value as a protocol name.
>
> Can someone familiar with the Http11NioProtocol connector help me with this
> problem?
>
> I also noticed that when a use a local instance of Tomcat (on the same host
> as my jmeter) with the same configuration the requests work (I suppose it's
> because the connection is faster and more data is available in the buffer
> without delay).
>
> Thanks a lot,
> Olaf Tomczak
>
>
>
>