I have just finished setting up a server on AWS ECS.

All of the configurations are identical to a different server I have, except for Apache version (from 2.2 to 2.4) and PHP version (from 5.3 to 5.6).

I have modified my index.php file to only printout the php_info(), but I keep getting:

Bad Request

Your browser sent a request that this server could not understand. Additionally, a 400 Bad Request error was encountered while trying to use an ErrorDocument to handle the request.

Apache/2.4.25 (Amazon) Server at xxx.yyy.com Port 80

I have looked at all the logs saved from my accesses and this is what I get from this specific access:


[Tue Jan 24 16:20:46.154208 2017] [suexec:notice] [pid 32139] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) 
[Tue Jan 24 16:20:46.249527 2017] [auth_digest:notice] [pid 32146] AH01757: generating secret for digest authentication ... 
[Tue Jan 24 16:20:46.250415 2017] [lbmethod_heartbeat:notice] [pid 32146] AH02282: No slotmem from mod_heartmonitor 
[Tue Jan 24 16:20:46.276823 2017] [mpm_prefork:notice] [pid 32146] AH00163: Apache/2.4.25 (Amazon) OpenSSL/1.0.1k-fips configured -- resuming normal operations 
[Tue Jan 24 16:20:46.276840 2017] [core:notice] [pid 32146] AH00094: Command line: '/usr/sbin/httpd'

access_log - - [24/Jan/2017:16:21:03 +0000] "GET / HTTP/1.1" 400 437 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36" - - [24/Jan/2017:16:21:04 +0000] "GET /favicon.ico HTTP/1.1" 400 437 "http://xxx.yyy.com/" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36"

ssl_access_log - - [24/Jan/2017:16:12:24 +0000] "GET / HTTP/1.1" 400 434 "-" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36" - - [24/Jan/2017:16:12:25 +0000] "GET /favicon.ico HTTP/1.1" 400 434 "https://xxx.yyy.com/" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36"

What could be causing my 400 status? Before you ask, I have installed mod_ssl, yes.

  • Capture the request and look at it. Preferably both client and server side. The most trivial point could be that they're different. – grochmal Jan 30 '17 at 22:54

Make sure you do not have illegal characters in your virtual hosts' ServerName.

I ran into this issue while migrating "sub_domain.test.com" from Apache 2.2 to 2.4.

The underscore in "sub_domain" caused Apache 2.4 to respond with 400 (Bad Request) but no further hint in the error log.

Also have a look at https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it

  • 1
    That was it for me. I was working with an apache httpd docker apline container. And I was failing to download files whenever using the hostname: httpd_filesver_7003. Even from whithin the machine. When trying to download the files using localhost no problem. I have now renamed the machine host name to httpd.fileserver.7003 and problem solved. It is extremlly anoying, that the ERRO LOG was not reporting any relevant information as to the "cause" of bad request – 99Sono Dec 18 '17 at 11:50
  • where were you @Chris ? I've struggled a week due to this underscore. (btw I'm on windows 10, Xampp) – shyammakwana.me Sep 26 '19 at 10:51

I'm having the same issue. I'm suspecting this fix that was included: CVE-2016-8743 Enforce HTTP request grammar corresponding to RFC7230 for request lines and request headers, to prevent response splitting and cache pollution by malicious clients or downstream proxies.

  • The RFC7230 screwup was mozilla's, i.e. it is Firefox development and 51.0 that is sending the bad HSTS priming request. But the User-Agent: string in OP's question suggest a request from Chrome. – grochmal Jan 30 '17 at 21:54
  • 1
    Just had an engineer on my Apache engineer add HttpProtocolOptions unsafe for testing and the request went through. My request was an openssl GET / HTTP/1.1 (simulating F5 Heath check monitor) – user7400387 Jan 30 '17 at 22:21
  • 1
    Oh, OK. You're suggesting that apache screwed-up in fixing that CVE. It is a valid point (+1). – grochmal Jan 30 '17 at 23:04
  • Fixed my issue. I found that prior to Apache 2.4.25 whitespaces in request were treated with more leniency. My F5 engineer had a whitespace between the HTTP/1.1 and the CRLF. In the F5 world it looks like this GET / HTTP/1.1 \r\nHOST: test.com\r\nConnection: close\r\n\r\n The whitespace between HTTP/1.1 and \r\nHost was the issue making the request non compliant. Previous version of Apache this was allowed. – user7400387 Jan 31 '17 at 14:54
  • I am also encountering this bug. There is no extra space in my request either; I'm pretty darn sure it's a bug in Apache, but it's strange that nobody has noticed. I ended up downgrading to Apache 2.2 to fix the issue. – user541686 Oct 1 '17 at 2:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.