400 errors

[Neil Sheth]

Looking more at some of the specific IPs triggering this, I think it may be
something automated.  I see a lot of things like
register->logout->register->logout - I think it's trying to create accounts
automatically.  Still not sure what the actual failure is though.

On Fri, Dec 10, 2010 at 2:57 AM, Neil Sheth <nsheth at gmail.com> wrote:

> A little more info - if I set the error_log to info, I see that these 400s
> correspond to "client closed prematurely connection"
>
> Given the volume of these I'm seeing, and only on this page (we aren't
> really seeing many 400s on other pages), I don't think it's just an issue of
> the user clicking away before the page returns.
>
>
> On Fri, Dec 10, 2010 at 2:41 AM, Neil Sheth <nsheth at gmail.com> wrote:
>
>> (We're running 0.8.53.)
>>
>>
>> On Fri, Dec 10, 2010 at 12:31 AM, Neil Sheth <nsheth at gmail.com> wrote:
>>
>>> We just changed over to another server, so far I don't see this issue
>>> happening, so perhaps it was indeed something related to some sort of faulty
>>> network config.
>>>
>>> I do still see some other 400s that I'm trying to track down.  They're
>>> almost all on the same page, it's on a post request to our registration
>>> page.  The entries all look like:
>>>
>>> 123.45.67.89 - - [09/Dec/2010:21:09:50 -0600] "POST /register.php
>>> HTTP/1.1" 400 0 "http://www.site.com/register.php?src=h" "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)"
>>>
>>> It generally seems to be IE that's triggering these (but I see IE6, IE7,
>>> and IE8, so not limited to one version).  I don't find any corresponding
>>> errors in my backend apache logs, nor in the nginx error log.
>>>
>>> Any insights would be appreciated.
>>>
>>> Thanks!
>>>
>>>
>>> On Tue, Dec 7, 2010 at 11:28 PM, Neil Sheth <nsheth at gmail.com> wrote:
>>>
>>>> I think you may be on to something, we are definitely seeing some
>>>> weirdness at a network level.  I found an older thread of mine, forgot about
>>>> it, this is the same problem.
>>>>
>>>> http://nginx.org/pipermail/nginx/2008-December/008667.html
>>>>
>>>> We're looking at the tcp/ip traffic in more detail, and things do not
>>>> look correct . . .
>>>>
>>>>
>>>> On Tue, Dec 7, 2010 at 8:18 PM, Mikhail Mazursky <ash2kk at gmail.com>wrote:
>>>>
>>>>> 2010/12/8 Neil Sheth <nsheth at gmail.com>:
>>>>> > Hello,
>>>>> >
>>>>> > Something I've been seeing for a long time here - I've posted long
>>>>> ago, but
>>>>> > was never able to find a solution.  Looking at our access logs, I see
>>>>> tons
>>>>> > of lines like (multiple times a minute)
>>>>> > 123.45.6.789 - - [07/Dec/2010:19:05:51 -0600] "-" 400 0 "-" "-"
>>>>> >
>>>>> > I changed my error_log to info, and I see a lot of corresponding
>>>>> entries
>>>>> > like:
>>>>> > recv() failed (104: Connection reset by peer) while reading client
>>>>> request
>>>>> > line
>>>>> >
>>>>> > I also set the following, but it doesn't seem to have helped, as I
>>>>> see a lot
>>>>> > of posts about this issue potentially being caused by large cookies:
>>>>> > large_client_header_buffers 8 4k;
>>>>> >
>>>>> > Thoughts?
>>>>>
>>>>> Hello,
>>>>>
>>>>> we used to have issues like this on two of our servers when the router
>>>>> was setup incorrectly and some ip packets of a TCP connection were
>>>>> routed not to the right server. Check your network.
>>>>>
>>>>> _______________________________________________
>>>>> nginx mailing list
>>>>> nginx at nginx.org
>>>>> http://nginx.org/mailman/listinfo/nginx
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20101210/c5db32c7/attachment.html>