|Summary:||REDIRECT_URL is not suitable for use in server-generated pages|
|Product:||Apache httpd-2||Reporter:||Nick Kew <nick>|
|Component:||Core||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
|Severity:||normal||CC:||apache-b6e, apache, erik5, jacob.perkins, leho, scott, stephane|
Description Nick Kew 2015-04-01 15:11:45 UTC
The non-standard REDIRECT_URL environment variable is introduced in UTIL_SCRIPT in r1053363 . Although the commit message is not clear, it appears to be intended to serve as a "return to" URL when the server executes an internal redirect. To serve correctly as such, it must return a full URL. Instead, it simply returns r->prev->uri, which is likely to be a relative URL, and may resolve incorrectly in an application. The example we recently encountered was using mod_auth_form, where we needed to patch util_script to generate a variable we could use with SSI in <input type="hidden" name="httpd_location_old" value="<!--#echo var="REDIRECT_URL"-->">. I propose to tidy my patch and apply in trunk. I'll also check whether pr53772 might be low-hanging fruit for this patch.
Comment 1 Graham Leggett 2015-09-26 23:40:55 UTC
Backported to v2.4.17.
Comment 2 Dave 2015-10-19 15:08:38 UTC
This patch appears to break the prexisting PHP behaviour (all versions, verified as far back as PHP 5.2). When cgi.fix_pathinfo=1, PHP will under some conditions set SCRIPT_NAME directly from REDIRECT_URL (noticed running under FastCGI). I'm not going to argue correct behaviour, only point out that the existing behaviour that was relied by another project has been broken by this change.
Comment 3 Nick Kew 2015-10-20 09:44:29 UTC
Dave, thanks for the heads-up. I had hoped in vain that a spell in trunk would pick up any such issues. REDIRECT_URL is a total misnomer for the PHP usage you describe, but I guess there's a lot of history in HTTPD and PHP patching API features. What do you think is the best fix now? 1) Leave it to PHP? 2) Introduce yet another env var? 3) Introduce a flag to switch between the two? 4) Other (please specify?)
Comment 4 Dave 2015-10-20 11:00:56 UTC
Heh - don't ask me, I'm not affiliated with either project! From my perspective we worked around the problem by backing out this patch on our 2.4.17 build, but we've been experiencing other issues with 2.4.17 that means we've reverted to 2.4.16 for now while I try to track them down. Obviously the correct behaviour is always preferred, but someone probably needs to give PHP the heads up to sort out their SCRIPT_NAME handling.
Comment 5 Scott Neader 2015-10-23 04:49:47 UTC
As a web hosting provider with customers affected by this change, my vote would be to offer some type of option to allow switching between the two, preferably something in .htaccess that is easily managed by the end-customer on a per-directory basis. - Scott
Comment 6 Marcelo Pedra 2015-10-23 14:54:23 UTC
I second Scott Neader. Please review what changes you have introduced in Apache 2.4.17 because 2.4.16 worked without problems. Since 2.4.17 we are seeing all kind of issues in websites using mod_rewrite. Mainly, CMS systems in general trying to use pretty permalinks, and specifically WordPress sites using cache plugins are currently unable to correctly rebuild their cache dirs. And since we use cPanel, we are stuck with 2.4.17 with no possibility to roll back to 2.4.16. Ideas are welcome. Also a bugfix (ASAP please).
Comment 7 Jacob P 2015-10-23 16:55:46 UTC
Here at cPanel we are reverting our 2.4.17 release and are going to re-release 2.4.16. Too many issues with mod_rewrite/REDIRECT_URL causing a *lot* of applications to stop working.
Comment 8 Marcelo Pedra 2015-10-27 22:14:55 UTC
I can confirm that after downgrading to 2.4.16, WordPress and other CMS went back to normal functioning. I work with WordPress, Joomla and Magento across different server/PHP configurations, and the fixing factor was the downgrade to Apache 2.4.16. Hopefully, this bug may not happen again as it difficulted operations to hundreds of sites. Thanks!
Comment 9 nathanjosiah 2015-11-03 23:39:24 UTC
I can confirm that this change broke several sites that I manage without me knowing due to automatic updates. Please fix this ASAP!
Comment 10 Eric Covener 2015-11-04 00:28:45 UTC
The next 2.4 release will revert back to the old behavior by default.
Comment 11 Gerbel 2015-11-12 04:50:39 UTC
I believe this patch in 2.4.x branch restores previous behavior https://github.com/apache/httpd/commit/7feb3c0999927f9d0d16f37c7bed13b58c09162f