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 
<olaf.tomc...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





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





Reply via email to