tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olaf Tomczak <>
Subject Re: Http11NioProtocol error 505 (or 400)
Date Tue, 28 Dec 2010 09:19:10 GMT

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

GET /0123456789012345678901234567890123456.htm HTTP/1.1
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
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
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 <>

> Hash: SHA1
> Olaf,
> On 12/27/2010 5:24 PM, Olaf Tomczak wrote:
> > 2010/12/27 Christopher Schultz <>
> >> 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
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAk0ZGxMACgkQ9CaO5/Lv0PCygACgv66l6yc6Wubf/szFbfgOm90B
> nEgAoI/MAXqpieNtwKr3p389EV6lyQy5
> =MsJZ
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message