Bug 1302797

Summary: PHP-FPM incorrectly handle Apache 2.4.x FastCGI Request OR HTTPd apache incorrectly send SCRIPT_FILENAME values.
Product: Red Hat Enterprise Linux 7 Reporter: gael THEROND <gael.therond>
Component: httpdAssignee: Web Stack Team <webstack-team>
Status: CLOSED ERRATA QA Contact: Jan Houska <jhouska>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.2CC: isenfeld, jhouska, jkaluza, luhliari, mfrodl, rcollet
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: httpd-2.4.6-41 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-04 08:10:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
HTTPd configuration files for this bug none

Description gael THEROND 2016-01-28 16:27:38 UTC
Description of problem:

As correctly described on this merge request: https://github.com/php/php-src/pull/1197/files

PHP in FPM mode do not handle properly balancer/FastCGI requests coming from an HTTPd Apache 2.4 using the SetHandler directive.

Version-Release number of selected component (if applicable):
PHP-FPM 5.4.16 - Apache 2.4

How reproducible:

Steps to Reproduce:
1.Configure a vhost with mod_vhost_alias.
2.Set a FileMatch directive catching php extension.
3.Set a SetHandler directive on the FileMatch section which delegate to a balanced proxy setup.

Actual results:
HTTP Result: 404 - File Not Found

Expected results:
HTTP Result: 200 - OK

Additional info:
If you take a look at the received packet on PHP-FPM, you'll clearly see that the SCRIPT_FILENAME variable contain bad informations.
Here is the sanitized content of the packet:


As you can see it, the SCRIPT_FILENAME variable should rather have been filed without the proxy:balancer://compute/ information coming from Apache.

Comment 7 gael THEROND 2016-03-17 17:29:09 UTC
Many thanks for the fix, I still have to test and validate it on our platform. I'll update this ticket accordingly.

Comment 8 gael THEROND 2016-05-16 12:06:22 UTC
Hi guys, any idea, when this fix will made its way to the upstream repository?
It kinda became quite important to have this feature for us to operate safely our PHP Base application.

Comment 10 Luboš Uhliarik ✈ 2016-08-31 11:22:43 UTC
(In reply to gael THEROND from comment #8)
> Hi guys, any idea, when this fix will made its way to the upstream
> repository?
> It kinda became quite important to have this feature for us to operate
> safely our PHP Base application.

Hi Gael,

have you meant, when this fix will be in RHEL repository? It is already in upstream.

We are currently working on the patch inclusion to RHEL, but we are not able to reproduce this bug. Would you mind to share with us more detailed reproducer? The best would be to attach your httpd configuration.


Comment 11 gael THEROND 2016-09-01 08:04:16 UTC
Created attachment 1196615 [details]
HTTPd configuration files for this bug

Comment 12 gael THEROND 2016-09-01 08:05:03 UTC
Hi Luboš!

I’m glad to hear some news from RH :D

Yes, when I said upstream I mean available in RH repositories.

Please find attached a redacted version of my HTTPd folder containing only relevant configuration files.

For information, Rémi COLLET, an active member of the #fedora IRC Chan do have the exact same problem.

I talked with him previously and he is the one who suggested me to fill for a bugzilla report.

Comment 15 errata-xmlrpc 2016-11-04 08:10:40 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.