How to diagnose error 400, bad request, after upgrading Apache

400apache-2.2http-headers

I'm the author of an open-source client-server application that seems to have stopped working on my own server after I upgraded to Apache 2.2.22. I now get http error 400, bad request, on all my client's POST requests. I get nothing in the apache error log, even though my LogLevel is currently set to "warn." A typical request looks like this:

POST /cgi-bin/spotter3/ServerOG.cgi HTTP/1.0
Accept: */*
User-Agent: OpenGrade
Content-Length: 143

/1EaFTX2Ae8yoveeee3pogKMumU
class=s2017/223
user=bcrowell
get_what=roster
client_date=2017-5-24 21:17:49
what=get_class_data
account=bcrowell

Is there a good way to diagnose this problem? Can I change something in my apache configuration file so that something informative will be written to my access log in this situation? Is there a "lint"-style utility for HTTP headers, or a parser that gives good errors and warnings? Is there anything about this request that looks like it would be archaic or deprecated?

Best Answer

First thing we can change the log level here to warn in the httpd.conf , Then we can check the error_log file in the apache there we will be able to find valuable information once we hit the url

Related Solutions

Redirecting requests that would result in an HTTP 400 (Bad Request) error (Apache 2.2)

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/ "/var/www/cgi-bin/"
ErrorDocument   400 /cgi-bin/handle400.pl

lukas$ cat /var/www/cgi-bin/handle400.pl

#!/usr/bin/perl
print "Content-type: text/html\n\n";
while (my ($key, $val) = each %ENV) {
        print "$key = $val<BR>\n";
}
exit 0;

Now when accessing the broken URL that would produce an error 400 Bad Request before, I now get the following (partial) output:

...
REDIRECT_REQUEST_METHOD = GET
REDIRECT_STATUS = 400
REMOTE_ADDR = xx.xx.xx.xx
REQUEST_URI = /%&%28%7B$%7Beval%28base64_decode%28$_SERVER%5BHTTP_EXECCODE%5D%29%29%7D%7D%7C.+%29&%/
GATEWAY_INTERFACE = CGI/1.1
SCRIPT_URL = /cgi-bin/handle400.pl
...

So you do get enough information to do a proper status code change and location redirect.

Ignore heartbeat in Apache access logs

I've not tested this, but, if you set an environment variable you should be able to switch which file it logs to:

SetEnvIf Request_URI "/fogbugz/heartbeat\.asp$" is_heartbeat_request=1
CustomLog /var/log/httpd/heartbeat_log combined env=is_heartbeat_request
CustomLog /var/log/httpd/access_log combined env=!is_heartbeat_request

Best Answer

Related Solutions

Redirecting requests that would result in an HTTP 400 (Bad Request) error (Apache 2.2)

Ignore heartbeat in Apache access logs

Related Topic