php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79549 PHP-FPM sends invalid headers '0\xd5e\xc8' to the web server
Submitted: 2020-04-30 23:18 UTC Modified: 2020-05-01 20:08 UTC
Votes:2
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: morozov at tut dot by Assigned:
Status: Verified Package: opcache
PHP Version: 7.4.5 OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: morozov at tut dot by
New email:
PHP Version: OS:

 

 [2020-04-30 23:18 UTC] morozov at tut dot by
Description:
------------
Under certain circumstances which I cannot currently isolate, PHP-FPM responds to the webserver (Apache) with certain invalid headers that result in a 500 response from apache.

The issue is only reproducible in a proprietary application. There are certain criteria I was able to identify which make the issue trigger. If I remove any of them, the issue goes away:

1. Opcache enabled.
2. header('Expires:'); header('Pragma:');  // note the absence of the value which is probably invalid. Sometimes the issue is also reproducible even w/o invalid headers
3. Response length. With all other parameters the same, a "[]" json response doesn't cause the issue but a valid 180-bytes response does.
4. Some seemingly unrelated function calls like file_get_contents().

Actual result:
--------------
Apache response:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator at 
 [no address given] to inform them of the time this error occurred,
 and the actions you performed just before this error.</p>
<p>More information about this error may be available
in the server error log.</p>
<p>Additionally, a 304 Not Modified
error was encountered while trying to use an ErrorDocument to handle the request.</p>
<hr>
<address>Apache/2.4.41 (Ubuntu) Server at sugarcrm.local Port 80</address>
</body></html>

Apache logs:

[Thu Apr 30 14:57:39.470700 2020] [http:error] [pid 73344:tid 140477684762368] [client 127.0.0.1:35104] AH02429: Response header name '0\xd5e\xc8' contains invalid characters, aborting request, referer: ...
[Thu Apr 30 14:57:39.725176 2020] [http:error] [pid 73311:tid 140478498461440] [client 127.0.0.1:35016] AH02429: Response header name '\x90\x84f\xc8' contains invalid characters, aborting request, referer: ...
[Thu Apr 30 15:06:12.065188 2020] [http:error] [pid 73344:tid 140478162917120] [client 127.0.0.1:39432] AH02429: Response header name '0\x85f\xc8' contains invalid characters, aborting request, referer: ...
[Thu Apr 30 15:14:17.448112 2020] [http:error] [pid 73344:tid 140478869321472] [client 127.0.0.1:43298] AH02429: Response header name 'p\x84f\xc8' contains invalid characters, aborting request, referer: ...
[Thu Apr 30 15:43:12.482083 2020] [http:error] [pid 73344:tid 140478877714176] [client 127.0.0.1:57656] AH02429: Response header name '@\x84f\xc8' contains invalid characters, aborting request, referer: ...
[Thu Apr 30 15:50:02.294075 2020] [http:error] [pid 73311:tid 140478246811392] [client 127.0.0.1:60500] AH02429: Response header name 'P\x84f\xc8' contains invalid characters, aborting request, referer: ...
[Thu Apr 30 15:50:05.837520 2020] [http:error] [pid 73311:tid 140478230025984] [client 127.0.0.1:33090] AH02429: Response header name ' \x84f\xc8' contains invalid characters, aborting request, referer: ...


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-05-01 00:59 UTC] requinix@php.net
-Summary: PHP-FPM sends wrong headers to the web server +Summary: PHP-FPM sends invalid headers '0\xd5e\xc8' to the web server
 [2020-05-01 00:59 UTC] requinix@php.net
Is there any way you can dump the full response from php-fpm to somewhere you can read it?
 [2020-05-01 01:35 UTC] morozov at tut dot by
What's the recommended way of intercepting traffic between a web server and PHP FPM? I use a local Unix socket for development. Should I switch to TCP/IP and use something like Wireshark?
 [2020-05-01 03:54 UTC] morozov at tut dot by
Please see the dump at https://gist.github.com/morozov/bfe35ea3298681cf75b6ba54d67d2575

Right before the empty Pragma: header there was supposed to be the Expires: one.
 [2020-05-01 04:20 UTC] requinix@php.net
-Status: Open +Status: Verified
 [2020-05-01 04:20 UTC] requinix@php.net
The important bit being

20:47:31.786 >>> process php-fpm [125706 -> 73344] len 152(152)
~Status: 304 Not Modified
X-Powered-By: PHP/7.4.5
Cache-Control: max-age=0, private
j
Pragma:
Content-Length: 2

ort

I've confirmed that whole thing is indeed 152 bytes.

You can take down the gist if you want, but just in case, please dump one of these outputs to a file and hang onto it in case it's useful.

So yeah, definitely screwy: there's leading garbage before the headers, clearly something weird happened to the Expires, and there's more garbage before the body.

Would you be able to try running on other PHP versions? I suggest 7.4.1 and a recent 7.3.


Separately, notice that this is a 304 but it comes with some output. If your application is responsible for emitting that (and given the Content-Length header I think it is), it's incorrect behavior that you should look into when you have the time.
 [2020-05-01 05:41 UTC] morozov at tut dot by
> Would you be able to try running on other PHP versions? I suggest 7.4.1 and a recent 7.3.

I tried 7.4.1 (also reproducible) and 7.3.17 (not reproducible). Please see the dumps in the updated gist.

> Separately, notice that this is a 304 but it comes with some output. If your application is responsible for emitting that (and given the Content-Length header I think it is), it's incorrect behavior that you should look into when you have the time.

Definitely. Thank you for pointing that out.
 [2020-05-01 20:08 UTC] morozov at tut dot by
> If your application is responsible for emitting that (and given the Content-Length header I think it is), it's incorrect behavior […]

FWIW, even with the issue fixed (no Content-* headers and body sent with a 304 response), the issue is still reproducible.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 17:01:58 2024 UTC