|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:||httpd||Assignee:||Web Stack Team <webstack-team>|
|Status:||CLOSED ERRATA||QA Contact:||Jan Houska <jhouska>|
|Version:||7.2||CC:||isenfeld, jhouska, jkaluza, luhliari, mfrodl, rcollet|
|Fixed In Version:||httpd-2.4.6-41||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2016-11-04 08:10:40 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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_ADMINfirstname.lastname@example.org 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