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: Luboš Uhliarik <luhliari>
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   
Whiteboard:
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:
Embargoed:
Attachments:
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:
Always

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:

    SERVER_NAME=polygon.polygon.lan
    SERVER_ADDR=192.168.0.100
    SERVER_PORT=443
    REMOTE_ADDR=192.168.0.10
    DOCUMENT_ROOT=/mnt/nfs/customers/polygon
    REQUEST_SCHEME=https
    CONTEXT_PREFIX
    CONTEXT_DOCUMENT_ROOT=/mnt/nfs/customers/polygon
    SERVER_ADMIN=exploit
    SCRIPT_FILENAME=proxy:balancer://compute//mnt/nfs/customers/polygon/index.php
    REMOTE_PORT=56984
    GATEWAY_INTERFACE=CGI/1.1
    SERVER_PROTOCOL=HTTP/1.1
    REQUEST_METHOD=GET
    QUERY_STRING
    REQUEST_URI=/index.php
    SCRIPT_NAME=/index.php

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.

Thanks
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.

https://rhn.redhat.com/errata/RHEA-2016-2534.html