Bad path for forms...and only forms! (Forms API & reverse proxy)

By chlojolo on 16 May 2006 at 22:27 UTC

I installed Drupal 4.7 behind a reverse proxy so that http://example.com/blah/drupal gets forwarded to http://someplaceelse.com/drupal. Rather than let it figure out my $base_url dynamically, I specified it as http://example.com/blah/drupal in the site's settings.php. The code base is installed in DOCUMENT_ROOT/drupal.

Everything seems to work, except for one thing. The stylesheets and images all load, and the links all work. This is because in the HTML they are given as absolute paths like "/blah/drupal/?q&node=1". I presume it's figuring out that it needs to add "/blah" based on the $base_url.

Form action URLs, on the other hand, don't do this. The Forms API states that the default value for the #action attribute is the value of request_uri, which in this case is going to be something like "/drupal/?q&node=1".

It seems weird to me that all the other URLs would be smart enough to figure out that the $base_url is going to affect them, but not the form action URL, but I suppose it can't be changed now, since all kinds of modules likely count on this behavior.

My workaround right now is to make the default value of #action to be the empty string, since that results in a form tag with no action, which means that browsers send the request to the current page. We'll see if any modules break. But what is the "right" way to deal with this problem?

Comments

reverse proxying forms actions

marc.zonzon commented 21 December 2006 at 11:03

I ran into the same problem, reverse proxy with different prefixes on the front-end and the drupal site. Everything working but server statistic and many forms (not all of them, search always worked the right way). A similar problem is decribed on This page, but the fix given does not apply when you have a prefix in both sites (the front-end and the proxied), and it break previously working forms.

I don' t know what is the right strategy, I have rewritten all my request_uri to the request_uri on the front-end (some work that could be done in apache with proxy_html, if you accept the overhead of parsing all your html on the front end!). I'm not yet sure it will not break something, it only seems to work
I give the code I placed at the end of function request_uri() in bootstrap.inc, it is still an ad-hoc code because it needs to be tested (or droped?)

// horrible hack, to test rev proxy prefix rewrite! MZ
if (isset($_SERVER["HTTP_X_FORWARDED_HOST"])){
  $local_prefix = '\/drupal';
  $proxy_prefix = '/foo';       
  $pattern = '/^' . $local_prefix . '(.*)$/';
  $replacement = $proxy_prefix . '${1}';
  $uri = preg_replace($pattern, $replacement, $uri);
}
return $uri;

I have had no time to look for the second problem, statistics allways set as origin (or referrrer url), the proxy, wich is useless; does somebody fixed it?

Marc