Bug: request_uri using Reverse Proxy affects form submit, css and js links

I forgot:

The config is using
Apache/2.2.3, PHP Version 5.1.6, MySQL 4.1
Reverse proxy is Apache

Bertrand

Sorry again, the page has been cut when I have submitted it (first time I post an issue). I continue here

Using the above configuration, Drupal will install properly but all action in forms using the 'default action path' are wrong. Example, for the node ?q=user, drupal will return form action="/dir/?q=user" but the right action path should be form action ="/www2/?q=user".

The problem comes form request_uri() function. The php server variable $_SERVER['REQUEST_URI'] will not return the www2 "virtual" directory.

Can anyone discuss on this situation ?

Thanks

Bertrand

I finally found that system_elements() is the function that is udes to set up default value for forms. Am I right ?

function system_elements() {
  // Top level form
  $type['form'] = array('#method' => 'post', '#action' => request_uri());

...

Setting #action to an absolute path may correct the problem

I do not know what would be the best practice at this point.

Bertrand

Additional info: list of entry for request_uri() function in drupal core
**************************************************

bootstrap.inc
**********

Line 467 : $cache = cache_get($base_root . request_uri(), 'cache_page');
Line 638 : function request_uri() {
Line 675 : $request_uri = $base_root . request_uri();

common.inc
*********

Line 1891 : cache_set($base_root . request_uri(), 'cache_page', $data, CACHE_TEMPORARY, drupal_get_headers());

locale.module
**********

Line 206 : db_query("INSERT INTO {locales_source} (location, source) VALUES ('%s', '%s')", request_uri(), $string);

system.module
***********
Line 58 : $type['form'] = array('#method' => 'post', '#action' => '/www2' . request_uri());
Line 601 : if (strpos(request_uri(), '?q=') !== FALSE) {

code-style.pl
**********
Line 73 : $msg = "the use of REQUEST_URI is prone to XSS exploits and does not work on IIS; use request_uri() instead";
Line 76 : $msg = "the use of REQUEST_URI is prone to XSS exploits and does not work on IIS; use request_uri() instead";

The bug still exist in 6.4.

I can provide links to demonstrate the problem (contact me using my e-mail address please).

I try to clarify the problem.

Imagine that you have a Drupal installation in the following directory:

dev/drupal

In a standard installation, you can reach the drupal login page at :

subdomain.domain.com/dev/drupal/user/login

In this case, the request_uri function will return:

/dev/drupal/user/login

which is correct to for the attributes action of the user login form

Using reverse proxy, we can configure domains to act differently

Example1:
Reverse Proxy configuration
www.yourdomain.com => subdomain.domain.com/dev/drupal/

If you try to reach the login page, everything is ok:
The reverse proxy received : www.yourdomain.com/user/login
The reverse proxy will send to the user the page : subdomain.domain.com/dev/drupal/user/login
In this case, the request_uri function will return /dev/drupal/user/login which is NOT correct to for the attributes action of the user login form (in this case /user/login is expected)

Example 2:
Reverse Proxy configuration
www.yourdomain1.com/www2/ => subdomain.domain.com/dev/drupal/
Note the www2 is not a directory, it is a reverse proxy rule

If you try to reach the login page, everything is ok:
The reverse proxy received : www.yourdomain.com/www2/user/login
The reverse proxy will send to the user the page : subdomain.domain.com/dev/drupal/user/login
In this case, the request_uri function will return /dev/drupal/user/login which is NOT correct to for the attributes action of the user login form. (in this case /www2/user/login is expected)

In this scenario, request_uri should be based on $base_uri (defined manually in this scenario) and the php variable $_SERVER["REQUEST_URI"]

Hope it clarify

The same problem occurs with css. Path are not correct with the above configuration

I tested this morning this code and it works fine. The use of $_SERVER["REQUEST_URI"] is not necessary.

function request_uri() {
  global $base_url;
  $parts = parse_url($base_url);
  return $parts['path'] . "/" . $_REQUEST['q'];
}

The code works fine in two installation with and without reverse proxy. Both are under linux installations.

I add a patch (first time I make one, then if not correct, just explain why)

The same problem exists in version 7.x-dev

This problems occurs if you use a reverse proxy with ProxyPreserveHost Off or commented in your config and if you do not use virtual host on the host server.

If you want to keep you config, you will have to patch Drupal else re configure the reverse proxy to have

ProxyPreserveHost On

and create a virtual host on your server:

Exemple :

ServerName domain.com
DocumentRoot /var/www/html/http/directory/

ServerName domain.com
ProxyPreserveHost On
ProxyPass / http://servername/
ProxyPassReverse / http://servername/
CustomLog logs/current/domain.com/access.log vcombined
ErrorLog logs/current/domain.com/error.log