500 internal server - AH02429: Response header name

Solution 1:

You have a key header with invalids characters, it wasn't a problem untill security fix CVE-2016-8743.

https://blog.tigertech.net/posts/apache-cve-2016-8743/

In my case wasApache + PHP and a whitespace before ":" like "X-CUSTOM-KEY :" and I haven't found other solution than changing the header.

Solution 2:

As @GroGz says, this issue is almost certainly caused (or rather exposed) by the fix to CVE-2016-8743 - the parsing of HTTP headers was made much more strict in an update to Apache released on 20 December 2016 (details at https://httpd.apache.org/security/vulnerabilities_24.html). It's likely your Perl script uses the module CGI::Carp which includes a "warningsToBrowser" subroutine. This subroutine puts warnings triggered by code issues in HTML comments embedded in the output of your program, rather than just logging them to the HTTPD logs. This subroutine is triggered like so:

warningsToBrowser(1);

If you trigger it before the HTTP headers have been sent in their entirety you will see an error similar to the one you describe.

The easy fix is to search your code for any occurrence of:

warningsToBrowser(1);

and change it to:

warningsToBrowser(0);

With this, the warning messages will only be sent to STDERR (like most HTTPD servers, Apache will direct STDERR to the server's error log). Since you say "the code's been working great for years" it's likely the warnings aren't too serious anyway. Check out http://perldoc.perl.org/5.8.9/CGI/Carp.html#MAKING-WARNINGS-APPEAR-AS-HTML-COMMENTS for a bit more information.

Solution 3:

I had this problem with a buggy java application that was returning a "Location: http://foo.bar\n" (note that \n at the end).

I didn't have access to the application source code to solve the problem, so I had to do a workaround by telling apache to fix the headers using mod_header

The solution was:

      Header edit Location "\n$" ""

I did some tests, created an application that returned a <!-- warning: teste header and solved it on apache with the following directive:

      Header always unset "<!-- warning"

If you can't fix the application, apache can remove/fix the header for you.