Bug 61202 - SCRIPT_NAME is broken in 2.4.26, path is stripped
Summary: SCRIPT_NAME is broken in 2.4.26, path is stripped
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy_fcgi (show other bugs)
Version: 2.5-HEAD
Hardware: PC Linux
: P2 major with 3 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: FixedInTrunk
: 61211 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-06-20 10:25 UTC by aidbmfqognnq6gizaigaqaaaaaaaa
Modified: 2017-07-18 16:49 UTC (History)
5 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description aidbmfqognnq6gizaigaqaaaaaaaa 2017-06-20 10:25:40 UTC
Hi,


with 2.4.26 the variable SCRIPT_NAME, which is passed to fcgi applications such as php-fpm, no longer contains the full uri path.

ex.
http://server.example/~phil/blah.php

$_SERVER['SCRIPT_NAME'] /blah.php
$_SERVER['REQUEST_URI'] /~phil/blah.php
$_SERVER['SCRIPT_FILENAME'] /home/phil/.public_html/blah.php
$_SERVER['CONTEXT_DOCUMENT_ROOT'] /home/phil/.public_html
$_SERVER['CONTEXT_PREFIX'] /~phil

SCRIPT_NAME should be /~phil/blah.php, not /blah.php.


Kind regards

Phil
Comment 1 aidbmfqognnq6gizaigaqaaaaaaaa 2017-06-20 10:30:57 UTC
SCRIPT_NAME is set to the correct value when using ProxyFCGIBackendType GENERIC:

$_SERVER['SCRIPT_NAME'] /~phil/blah.php
$_SERVER['REQUEST_URI'] /~phil/blah.php
$_SERVER['SCRIPT_FILENAME'] /home/phil/.public_html/blah.php
$_SERVER['CONTEXT_DOCUMENT_ROOT'] /home/phil/.public_html
$_SERVER['CONTEXT_PREFIX'] /~phil
Comment 2 Dave 2017-06-20 14:32:32 UTC
The GENERIC/FPM code path change in mod_proxy_fcgi.c looks very wrong, particularly the "TODO" part responsible for stripping off leading directory components (390:392) and appending PATH_INFO to SCRIPT_NAME (RFC3875 says no):

    379     if (fpm || apr_table_get(r->notes, "virtual_script")) {
    380         /*
    381          * Adjust SCRIPT_NAME, PATH_INFO and PATH_TRANSLATED for PHP-FPM
    382          * TODO: Right now, PATH_INFO and PATH_TRANSLATED look OK...
    383          */
    384         const char *pend;
    385         const char *script_name = apr_table_get(r->subprocess_env, "SCRIPT_NAME");
    386         pend = script_name + strlen(script_name);
    387         if (r->path_info && *r->path_info) {
    388             pend = script_name + ap_find_path_info(script_name, r->path_info) - 1;
    389         }
    390         while (pend != script_name && *pend != '/') {
    391             pend--;
    392         }
    393         apr_table_setn(r->subprocess_env, "SCRIPT_NAME", pend);
    394         ap_log_rerror(APLOG_MARK, APLOG_TRACE4, 0, r,
    395                       "fpm:virtual_script: Modified SCRIPT_NAME to: %s",
    396                       pend);
    397     }

Other than rolling back the whole module to 2.6.25, it does indeed look like setting ProxyFCGIBackendType to GENERIC (which appears to work fine with FPM for me, too) is the solution.
Comment 3 Jacob Champion 2017-06-22 22:12:25 UTC
Thanks for the report. We're currently discussing the right fix; as many of you have already discovered, using a GENERIC backend type will revert to the 2.4.25 behavior. If you're a 2.4.26 user, you probably should not expect the current behavior of the FPM BackendType (nor its current status as the "default" setting) to remain as-is.

Note that the 2.4.25 behavior won't work for everyone either. My eventual goal is to return us (by default) to the 2.4.20 behavior that seemed to work for many PHP-FPM users, and letting users of other "incompatible" (i.e. correct) FCGI daemons use the new ProxyFCGISetEnvIf directive if they need it. Sorry for introducing this mess with my fix to bug 59618.
Comment 4 Eric Covener 2017-06-22 22:40:22 UTC
(In reply to aidbmfqognnq6gizaigaqaaaaaaaa from comment #0)
> Hi,
> 
> 
> with 2.4.26 the variable SCRIPT_NAME, which is passed to fcgi applications
> such as php-fpm, no longer contains the full uri path.

Hi Phil, I also agree it looks pretty bogus. Out of curiosity, what kind of config do you use to map these requests to proxy_fcgi?
Comment 5 Tomas Merta 2017-06-23 07:28:01 UTC
Same bug after upgrade:

Config for backend:

<FilesMatch \.php$>
   SetHandler "proxy:unix:/var/run/php-fpm/vu008621.sock|fcgi://vu008621"
</FilesMatch>
<Proxy fcgi://vu008621 disablereuse=On>
</Proxy>
Comment 6 Eric Covener 2017-06-23 11:06:40 UTC
(In reply to Tomas Merta from comment #5)
> Same bug after upgrade:
> 
> Config for backend:
> 
> <FilesMatch \.php$>
>    SetHandler "proxy:unix:/var/run/php-fpm/vu008621.sock|fcgi://vu008621"
> </FilesMatch>
> <Proxy fcgi://vu008621 disablereuse=On>
> </Proxy>

Please open a new bug report. This PR is about a regression.
Comment 7 Eric Covener 2017-06-23 12:16:15 UTC
(In reply to Eric Covener from comment #6)
> (In reply to Tomas Merta from comment #5)
> > Same bug after upgrade:
> > 
> > Config for backend:
> > 
> > <FilesMatch \.php$>
> >    SetHandler "proxy:unix:/var/run/php-fpm/vu008621.sock|fcgi://vu008621"
> > </FilesMatch>
> > <Proxy fcgi://vu008621 disablereuse=On>
> > </Proxy>
> 
> Please open a new bug report. This PR is about a regression.

Sorry, I understand what you wrote now. Thanks for sharing your affected config.
Comment 8 aidbmfqognnq6gizaigaqaaaaaaaa 2017-06-23 14:09:18 UTC
Hi Eric,


(In reply to Eric Covener from comment #4)
> Hi Phil, I also agree it looks pretty bogus. Out of curiosity, what kind of
> config do you use to map these requests to proxy_fcgi?

I guess it's a very common config:

<IfModule proxy_fcgi_module>
    ProxyFCGIBackendType GENERIC
    <FilesMatch \.php$>
        SetHandler "proxy:unix:/run/php-fpm/www.sock|fcgi://fpm-www"
    </FilesMatch>
</IfModule>
Comment 9 Jacob Champion 2017-06-23 17:08:45 UTC
*** Bug 61211 has been marked as a duplicate of this bug. ***
Comment 10 Jacob Champion 2017-06-29 18:08:43 UTC
Checked into trunk as r1800306 and proposed for backport to 2.4.x.
Comment 11 Yann Ylavic 2017-07-18 16:49:16 UTC
Backported to 2.4.27 with r1800618.