(JoomlaCode Issue Tracker: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=33919&start=0)

Don't overwrite the path, query & fragment in the 'uri.request' config key.

The uri.request config key is (obviously) supposed to represent the URI requested by the client. However, it is inadvertently being overwritten so as to become the base URI of the Joomla! installation.

The only current use of uri.request is in JApplicationWeb::redirect(), and then it is only used if the redirect destination is a relative path.

How to test:

Install Joomla! from the current master branch (which must include the recent commit f1fab1e) with the "Test English (GB) Sample Data" sample data on an apache server. Put the Joomla! installation at 2 subdirectory levels below the webserver root. For example, assume the Joomla! base installation is at:

http://example.com/foo/bar/index.php

In the site configuration, enable:

Search Engine Friendly URLs Use URL rewriting Adds Suffix to URL

Enable the System/Redirect plugin

copy htaccess.txt to .htaccess

In the Redirect component, create a redirect with a relative path as a destination:

http://example.com/foo/bar/growers/missing.html -> 23-happy-orange-orchard.html

Attempt to visit the 'missing.html' URL.

The expected result is that the URI of the original request would be used as a basis for creating the redirect and the end result would be:

http://example.com/foo/bar/growers/23-happy-orange-orchard.html

The actual result of the redirect is:

http://example.com/foo/23-happy-orange-orchard.html

Note that the relative path of the redirect's destination is incorrectly evaluated relative to the directory that's one level above the base Joomla! installation.

Analysis:

In JApplicationWeb::loadSystemUris(), a cached JUri instance is created from the 'uri.request' config key:

 $uri = JUri::getInstance($this->get('uri.request'));

The path of that cached JUri instance is then immediately modified:

 $uri->setPath(...);

Later, when JApplicationWeb::redirect() is invoked, the cached JUri instance of 'uri.request' is again retrieved and used to construct the redirect for the relative path destination. But because the cached JUri had been modified, the redirect is incorrectly contstructed.

Changes in this PR:

Avoid modifying the cached JUri instance of the 'uri.request' config key.

Eliminate multiple calls to rtrim(). Instead, call it just once.

When creating the 'uri.route' config key, don't blindly perform a substr_replace() without first confirming that what you are replacing is what you think it is. (The 'uri.route' config key does not appear to be used anywhere at this time.)