Hot answers tagged 400
Just to expand on MrTuttle's answer, the 400 errors I've investigated in the wild are typically someone trying (unsuccessfully) to exploit your webserver, typically because they haven't noticed that you're not running a vulnerable version, or they just don't care. A fair proportion of the 404 errors I get on my sites are in the same boat -- attempts to ...
Based on what you are seeing, if the same IPs logging the errors can later successfully access the site, then it is probably very safe to ignore the infrequent errors for the rational that you have presented.
You could define a custom ErrorDocument for the 400 Errors like so: ErrorDocument 400 /cgi-bin/handle400.cgi and then have that cgi (or php or servlet or whatever) do the header rewriting and location redirecting. EDIT: because of Jacek's answer I just tested above solution to confirm it works on Apache 2.2. My Server Config: ScriptAlias /cgi-bin/ ...
Kudos for actually reviewing your logs! I'd ignore the 400 errors. 99.999% of the time, they're client-side, and completely outside your purview; network flakeyness or a spyware-ridden browser, in my experience.
It didn't send an HTTP version string (HTTP/1.1 or HTTP/1.0), that client is not speaking correct HTTP. It should most certainly get a 400 Bad Request response. See RFC 2616: The request could not be understood by the server due to malformed syntax.
This error seems to come from a Gunicorn backend, not from Nginx. You can change it's limit by passing the parameter --limit-request-line or set limit_request_line. You can see a description here if you search for the string limit_request_line.
After trying many things, it turns out that this isn't possible. I opened a ticket on HTTPD's Bug Tracker - which was closed with Won't Fix. They say that: Marking as wontfix, when a request is malformed, the server isn't willing to do further processing to serve a custom errordocument out of the filesystem (your error page should have told you a ...
I tracked it down by looking at the IIS error log in systemroot\System32\LogFiles\HTTPERR. There I saw that the cause of the 400 was HOSTNAME. From there I determined that localhost was being resolved to a different IP address than the one on which IIS was listening.
I was looking in the wrong place. For Errors, you need to look in systemroot\System32\LogFiles\HTTPERR. http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/bcabdcfb-2421-4eab-b5fb-777c791daaa9.mspx?mfr=true
check this articles KB810957 which explains the cause of the issue and UploadReadAheadSize is the solution for the same. Let me know if that helps.
Only top voted, non community-wiki answers of a minimum length are eligible