Not surprisingly (since nag works fine here), it returns the same as 
with mod_php:

_SERVER["REQUEST_URI"]   => "/does/not/matter"
_SERVER["REDIRECT_URL"] => "/does/not/matter"

That is interesting. Can you run the tests mentioned in the first 
comment of this bug? Would be good to see what the 2.4 behaviour is.

Anyway, Apache 2.2 is still the default for the latest CentOS and 
Debian releases, so I believe it's worth making this change which will 
so far only break some special setups which are not standard.

Interesting. I'm using apache2.4 + mod_proxy_fcgi + PHP_FPM and with 
that combination there is no problem saving a task in nag. So the test 
case may not be so simple after all.

So the question is whether this is a better use case than the ones I 
mentioned, namely using Horde in various "normal" environments that 
just happen to be not Apache+mod_php.

Internal redirects isn't anything we use inside Horde, but it may well 
be used in the user's Apache configuration. I don't recall the exact 
use case anymore, but it may have occurred when moving services around 
during our web server redesigns, to keep old URLs intact.

When would that happen? As stated, REDIRECT_URL will return the 
redirected URL, e.g. rampage.php, but not the requested URL, for 
example /nag/t/save. There's a "simple" test case: install horde on 
apache2+mod_fastcgi or php-fpm, try to create/save a task in nag. It 
will produce an error.

The single commit you referenced does not state any use cases, but it 
would be good to know _what_  would break in this case. I haven't 
noticed anything yet, and I've tested imp, kronolith, nag, ansel 
(including slugs & password), wicked, mnemo, activesync, 
caldav+carddav and gollem (most of them with and without URL 
rewriting) with the change and none of them had a problem.

REDIRECT_URL must be used if using Apache redirects though. See 
https://github.com/horde/horde/commit/a9b1cbd21e99e2483ea3a088380b89fb775dfc4c

Thanks, it took me a whole day to figure out the problem with my 
PHP-FPM installation of Horde (and I only found this bug _after_ I 
knew what the problem was). I think it should be tested with nginx 
also, but from what I read on other bugtrackers[1][2] it's net even 
present on nginx.

[1] https://github.com/photo/frontend/pull/1134
[2] https://drupal.org/node/1424678

Relying on $_SERVER["REDIRECT_URL"] (before $_SERVER["REQUEST_URI"]) 
for a valid URL causes problems when using php-fastcgi or php-fpm. 
e.g. rampage won't work in these setups.

A simple test using apache 2.2 + mod_rewrite yields the following results:
Setup:
* .htaccess File inside docroot with content: RewriteRule ^(.*)$ 
test.php [QSA,L]
* GET-URL: http://something/does/not/matter

test.php served using mod_php:
_SERVER["REQUEST_URI"]   => "/does/not/matter"
_SERVER["REDIRECT_URL"] => "/does/not/matter"

test.php served using php-fastcgi (mod_fastcgi):
_SERVER["REQUEST_URI"]   => "/does/not/matter"
_SERVER["REDIRECT_URL"] => "/test.php"

test.php served using php-fpm (+mod_fastcgi):
_SERVER["REQUEST_URI"]   => "/does/not/matter"
_SERVER["REDIRECT_URL"] => "/test.php"

Classes using REDIRECT_URL before REQUEST_URI:
* Horde_Core_Factory_Request
* Horde_Controller_Request_Mock