Since upgrading from Apache 2.4.59 to Apache 2.4.61 I see errors from php-fpm backends for url paths containing spaces: (domain name was changed here to example.com for privacy purposes) Request: curl http://example.com/info%201.php Error Log (with LogLevel set to trace6) for Apache 2.4.61: > [2024-07-17 10:34:52.254685] [proxy:trace2] example.com X.X.X.X:50048 *: fixup UDS from proxy:unix:/run/php-fpm/8.2/testuser.sock|fcgi://localhost/home/www/example.com/info 1.php: fcgi://localhost/home/www/example.com/info 1.php (/run/php-fpm/8.2/testuser.sock) > [2024-07-17 10:34:52.254717] [proxy_fcgi:trace1] example.com X.X.X.X:50048 canonicalising URL //localhost/home/www/example.com/info 1.php > [2024-07-17 10:34:52.254726] [proxy_fcgi:debug] example.com X.X.X.X:50048 AH01060: set r->filename to proxy:fcgi://localhost/home/www/example.com/info%201.php > [2024-07-17 10:34:52.254739] [proxy:trace2] example.com X.X.X.X:50048 fcgi: found worker fcgi://localhost for fcgi://localhost/home/www/example.com/info%201.php > [2024-07-17 10:34:52.254744] [proxy:debug] example.com X.X.X.X:50048 AH01143: Running scheme fcgi handler (attempt 0) > [2024-07-17 10:34:52.254754] [proxy_fcgi:debug] example.com X.X.X.X:50048 AH01076: url: fcgi://localhost/home/www/example.com/info%201.php proxyname: (null) proxyport: 0 > [2024-07-17 10:34:52.254759] [proxy_fcgi:debug] example.com X.X.X.X:50048 AH01078: serving URL fcgi://localhost/home/www/example.com/info%201.php > [2024-07-17 10:34:52.254803] [proxy:debug] example.com AH00942: FCGI: has acquired connection for (localhost:8000) > [2024-07-17 10:34:52.254814] [proxy:debug] example.com X.X.X.X:50048 AH00944: connecting fcgi://localhost/home/www/example.com/info%201.php to localhost:8000 > [2024-07-17 10:34:52.254824] [proxy:debug] example.com X.X.X.X:50048 AH02545: fcgi: has determined UDS as /run/php-fpm/8.2/testuser.sock (for localhost:8000) > [2024-07-17 10:34:52.254840] [proxy:debug] example.com X.X.X.X:50048 AH00947: connecting /home/www/example.com/info%201.php to /run/php-fpm/8.2/testuser.sock:0 (localhost:8000) > [2024-07-17 10:34:52.254994] [proxy:debug] example.com AH02823: FCGI: connection established with Unix domain socket /run/php-fpm/8.2/testuser.sock (localhost:8000) > [2024-07-17 10:34:52.259420] [proxy_fcgi:error] example.com X.X.X.X:50048 AH01071: Got error 'Primary script unknown' > [2024-07-17 10:34:52.259547] [proxy_fcgi:trace4] example.com X.X.X.X:50048 Headers from script 'info%201.php': > [2024-07-17 10:34:52.259571] [proxy_fcgi:trace4] example.com X.X.X.X:50048 Status: 404 Not Found > [2024-07-17 10:34:52.259604] [proxy_fcgi:trace1] example.com X.X.X.X:50048 Status line from script 'info%201.php': 404 Not Found > [2024-07-17 10:34:52.259617] [proxy_fcgi:trace4] example.com X.X.X.X:50048 Content-type: text/html; charset=UTF-8 > [2024-07-17 10:34:52.259686] [proxy:debug] example.com AH00943: FCGI: has released connection for (localhost:8000) The whitespace in the filename path which is send to the fpm backend is clearly url encoded, and the fpm backend can't find that file. However in Apache 2.4.59 this was not the case, and this was working properly: > [2024-07-17 13:26:24.090205] [proxy:trace2] example.com X.X.X.X:57720 fcgi: found worker fcgi://localhost for unix:/run/php-fpm/8.2/testuser.sock|fcgi://localhost/home/www/example.com/info 1.php > [2024-07-17 13:26:24.090216] [proxy:trace2] example.com X.X.X.X:57720 *: rewrite of url due to UDS(/run/php-fpm/8.2/testuser.sock): fcgi://localhost/home/www/example.com/info 1.php (proxy:fcgi://localhost/home/www/example.com/info 1.php) > [2024-07-17 13:26:24.090223] [proxy:debug] example.com X.X.X.X:57720 AH01143: Running scheme unix handler (attempt 0) > [2024-07-17 13:26:24.090242] [proxy_fcgi:debug] example.com X.X.X.X:57720 AH01076: url: fcgi://localhost/home/www/example.com/info 1.php proxyname: (null) proxyport: 0 > [2024-07-17 13:26:24.090252] [proxy_fcgi:debug] example.com X.X.X.X:57720 AH01078: serving URL fcgi://localhost/home/www/example.com/info 1.php > [2024-07-17 13:26:24.090299] [proxy:debug] example.com AH00942: FCGI: has acquired connection for (localhost:8000) > [2024-07-17 13:26:24.090315] [proxy:debug] example.com X.X.X.X:57720 AH00944: connecting fcgi://localhost/home/www/example.com/info 1.php to localhost:8000 > [2024-07-17 13:26:24.090322] [proxy:debug] example.com X.X.X.X:57720 AH02545: fcgi: has determined UDS as /run/php-fpm/8.2/testuser.sock (for localhost:8000) > [2024-07-17 13:26:24.090348] [proxy:debug] example.com X.X.X.X:57720 AH00947: connecting /home/www/example.com/info 1.php to /run/php-fpm/8.2/testuser.sock:0 (localhost:8000) > [2024-07-17 13:26:24.090438] [proxy:debug] example.com AH02823: FCGI: connection established with Unix domain socket /run/php-fpm/8.2/testuser.sock (localhost:8000) > [2024-07-17 13:26:24.634856] [proxy_fcgi:trace4] example.com X.X.X.X:57720 Headers from script 'info 1.php': > [2024-07-17 13:26:24.634878] [proxy_fcgi:trace4] example.com X.X.X.X:57720 Content-type: text/html; charset=UTF-8 > [2024-07-17 13:26:24.634901] [proxy:debug] example.com AH00943: FCGI: has released connection for (localhost:8000) Used vhost/proxy config: > <VirtualHost *> > ServerName example.com > DocumentRoot "/home/www/example.com" > <FilesMatch "\.php$"> > SetHandler "proxy:unix:/run/php-fpm/8.2/testuser.sock|fcgi://localhost" > </FilesMatch> > </VirtualHost> 7 substitutions on 7 lines
Looks like a candidate for 2.4.64, CGI spec says: 4.1.13. SCRIPT_NAME The SCRIPT_NAME variable MUST be set to a URI path (not URL-encoded) which could identify the CGI script (rather than the script's output). The syntax is the same as for PATH_INFO (section 4.1.5) So I think when we recenly added this canonicalization, we were too aggressive. I think we need a version that focuses on delimiters only (maybe even just the problematic ?) classic bug with lots of trivia/info https://bz.apache.org/bugzilla/show_bug.cgi?id=51517
I think SCRIPT_NAME is still the same as before (2.4.59) since it's based on r->uri or r->path_info (IIUC) and we only canonicalize r->filename? SCRIPT_FILENAME has changed from ".../info 1.php" to ".../info%201.php" in this case though, but I can't find SCRIPT_FILENAME in the spec.. We already had issues with what php-fpm does with SCRIPT_FILENAME, all the FCGI_MAY_BE_FPM jazz. IMHO having SCRIPT_FILENAME not be the same depending on whether ProxyPass or SetHandler is used (like we had before) is not good anyway, whether both should or not be encoded I don't know..
We ran into the same problem a couple days back and ended up having to rollback our servers to 2.4.59. In our case it was due to spaces within a folder name, causing any PHP scripts down-tree of that folder to return 404 errors in 2.4.61 (for example "www.example.com/folder name/script.php" and "www.example.com/folder name/subfolder/test2.php"). I think that was pretty clear from how the original poster described the issue, but figured it didn't hurt to clarify that extra bit.
(In reply to Chris from comment #3) > We ran into the same problem a couple days back and ended up having to > rollback our servers to 2.4.59. > > In our case it was due to spaces within a folder name, causing any PHP > scripts down-tree of that folder to return 404 errors in 2.4.61 (for example > "www.example.com/folder name/script.php" and "www.example.com/folder > name/subfolder/test2.php"). > > I think that was pretty clear from how the original poster described the > issue, but figured it didn't hurt to clarify that extra bit. also w/ SetHandler style of config?
Yes also using SetHandler here. Here's an exmaple I pulled real quick: > <IfModule proxy_fcgi_module> > <FilesMatch \.(phtml|php[0-9]*)$> > SetHandler proxy:unix:/opt/cpanel/ea-php83/root/usr/var/run/php-fpm/e18adaedd0965f51198d600818c258525fea9ef2.sock|fcgi://www.example.com > </FilesMatch> > </IfModule>
Created attachment 39817 [details] Proxy FCGI nocanon from SetHandler If proxy_fcgi_canon() should not encode spaces when called from SetHandler maybe this is a the way to go..
(In reply to Eric Covener from comment #1) > Looks like a candidate for 2.4.64, CGI spec says: 2.4.63 rather.
We ran into the same problem but with different special characters. Also updated from 2.4.59 to 2.4.61. After the update "http://domain.com/ja/アダプタ/index.php" is encoded to "/path_to_docroot/ja/%E3%82%A2%E3%83%80%E3%83%97%E3%82%BF/index.php" in the filesystem. Jul 18 09:28:22 server apache2[657291]: [proxy_fcgi:debug] [pid 657291:tid 657383] mod_proxy_fcgi.c(123): [client ***] AH01060: set r->filename to proxy:fcgi://user-php82fpm/path_to_docroot/ja/%E3%82%A2%E3%83%80%E3%83%97%E3%82%BF/index.php We fixed it with a symlink for now, which isn´t a good solution. lrwxrwxrwx 1 user group 12 Jul 17 13:29 %E3%82%A2%E3%83%80%E3%83%97%E3%82%BF -> アダプタ
We are seeing this error as well, with php scripts which have spaces in their filenames. Temporary fix is to revert to 2.4.59. 2.4.60 & .62 show the same broken behaviour.
Could you please try with the patch that was attached by Yann? I tried a simple example with a german "ä" umlaut encoded in UTF-8 as %C3%A4. It was broken with 2.4.62 and worked with the patch.
The patch solves the problem. Thank you for this solution.
I just tested the attached patch from Yann with apache 2.4.61 for paths containing spaces and non-ascii characters (e.g. 'アダプタ') and it worked correctly again. Thanks!
The proposed patch is possibly not complete, I started a dev@ discussion here: https://lists.apache.org/thread/m3gckqpp9b30t26xgfjbnhtzm9166gsd
(In reply to Rainer Jung from comment #10) > Could you please try with the patch that was attached by Yann? > I tried a simple example with a german "ä" umlaut encoded in UTF-8 as > %C3%A4. It was broken with 2.4.62 and worked with the patch. I can confirm this patch works with 2.4.62 Our context was spaces in some php filenames rather than spaces in the dirpath.
I ran into this issue today and finally landed here. I see the patch but not being well versed in installing them can someone point me in the right direction on how to install that patch in RHEL?