Return-Path: 
 <users-return-221083-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org>
Delivered-To: apmail-tomcat-users-archive@www.apache.org
Received: (qmail 99094 invoked from network); 19 Jan 2011 22:51:03 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 19 Jan 2011 22:51:03 -0000
Received: (qmail 29393 invoked by uid 500); 19 Jan 2011 22:51:00 -0000
Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org
Received: (qmail 29310 invoked by uid 500); 19 Jan 2011 22:50:59 -0000
Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@tomcat.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@tomcat.apache.org>
List-Post: <mailto:users@tomcat.apache.org>
List-Id: <users.tomcat.apache.org>
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Delivered-To: mailing list users@tomcat.apache.org
Received: (qmail 29300 invoked by uid 99); 19 Jan 2011 22:50:59 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Jan 2011 22:50:59 +0000
X-ASF-Spam-Status: No, hits=0.7 required=10.0
	tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [76.96.59.211] (HELO QMTA11.westchester.pa.mail.comcast.net)
 (76.96.59.211)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Jan 2011 22:50:52 +0000
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59])
	by QMTA11.westchester.pa.mail.comcast.net with comcast
	id xah91f0071GhbT85BaqXYH; Wed, 19 Jan 2011 22:50:31 +0000
Received: from [192.168.1.201] ([69.143.109.145])
	by omta07.westchester.pa.mail.comcast.net with comcast
	id xaqW1f00m38FjT13TaqXre; Wed, 19 Jan 2011 22:50:31 +0000
Message-ID: <4D376AB5.20409@christopherschultz.net>
Date: Wed, 19 Jan 2011 17:50:29 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Request Line Truncated and Caused 501
References: <B7554865-0B7D-40F1-8193-7C19607625B7@gmail.com>
 <DD9C3C64B29B48989CE14113AE832621@phoenix>
In-Reply-To: <DD9C3C64B29B48989CE14113AE832621@phoenix>
X-Enigmail-Version: 1.2a1pre
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason,

On 1/19/2011 3:05 PM, Jason Pyeron wrote:
>> -----Original Message-----
>> From: Yuesong Wang > Sent: Wednesday, January 19, 2011 14:55
>> To: users@tomcat.apache.org
>> Subject: Request Line Truncated and Caused 501
>>
>> Hi,
>>
>> I have tomcat 6.0.29 configured using the NIO connector 
>> running on linux. My access log shows strange 501 errors like this:
>>
> 
> Does the NIO think it is on windows?

Why would that matter?

>> 86.24.156.114 - - [19/Jan/2011:14:41:28 -0500] "eferer: 
>> /static/r07/sh30.html " 501 1235 "-" "-"
>> 41.203.64.251 - - [19/Jan/2011:14:39:18 -0500] "ET <actual 
>> url> HTTP/1.1" 501 1220 "<actual referrer>" "Mozilla/4.0 
>> (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; 
>> GTB6.6; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET 
>> CLR 3.0.30729; Media Center PC 6.0; CPNTDF; .NET4.0C)"
>>
> 
> If chomping off the 0x0A when there is none, you could get this.

HTTP protocol says lines end with CR LF.

Perhaps the client is broken? It says MSIE, so it probably is. :)

The first line of the request shouldn't contain a leading CR or LF and
should start with an HTTP verb (like GET). It looks like "GET" is being
truncated to "ET" at some point.

>> I 
>> thought it had to do with the maxHttpHeaderSize being too 
>> small, and tried to reproduce it but couldn't. I suspect the 
>> http request itself is malformed, but can't be sure because I 
>> can't get to the raw request (RequestDumperValve happens 
>> after the raw request is parsed I think).
>>
>> Any idea what the problem may be or how to go about 
>> investigating this?

Can you search your access log for requests that don't start with valid
HTTP verbs? That might help you narrow down what conditions cause the
requests to get mangled. Maybe there really is some broken client out there.

What % of requests does this represent? What opportunities do you have
to reconfigure the server and continue to collect data?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk03arUACgkQ9CaO5/Lv0PA56QCePMcmTox8zkujlks+Mz0O8ngN
sF8AoK7ci3AWd5d3me2ALI/nfpwRteyS
=iUNt
-----END PGP SIGNATURE-----

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