Posted by ryan_courtnage on January 6, 2009 at 8:00pm
14 followers
| Project: | Drupal core |
| Version: | 6.14 |
| Component: | base system |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Hi,
I'm using Zen 6.x-1.0-beta3.
When Drupal is sitting behind a reverse-proxy (ie: nginx), error pages (404 or access denied) will have 4 hex characters echoed above the page html content. The characters are seemingly random (ie: "24cb").
This may not sound like a Zen problem, but the problem only occurs when using the vanilla Zen theme, or any sub-theme of Zen.
Does Zen have any logic in it that could possibly result in characters echoing above the HTML content?
Thanks
Comments
#1
I should mention that this problem is specific to being behind the reverse-proxy, which will set some $_SERVER variables that Drupal will use (ie: HTTP_X_FORWARDED_FOR).
In settings.php, the reverse proxy settings are set:
'reverse_proxy' => TRUE,
'reverse_proxy_addresses' => array('192.168.1.42'),
#2
Were you able to fix it? I'm having the same problem, only with a custom template.
#3
Hi,
Sorry, I never did solve this problem. It only happens in our staging environment, which is using nginx as the reverse proxy. On our production server we use a different proxy, and the problem doesn't appear.
#4
This isn't a problem with the Zen theme. This problem appears to be due to the fact that when Drupal sets a 404 or 403 header (in includes/common.inc) it's specifying HTTP/1.1 as the server protocol, eg:
drupal_set_header('HTTP/1.1 404 Not Found');This is a problem because apparently Nginx can only speak HTTP/1.0 to backend servers.
You can work around the problem by modifying the drupal_set_header function as follows:
function drupal_set_header($header = NULL) {
// We use an array to guarantee there are no leading or trailing delimiters.
// Otherwise, header('') could get called when serving the page later, which
// ends HTTP headers prematurely on some PHP versions.
static $stored_headers = array();
// this line fixes strange characters in 403/404 output when proxied behind nginx
$header = str_replace('HTTP/1.1', $_SERVER["SERVER_PROTOCOL"], $header);
if (strlen($header)) {
header($header);
$stored_headers[] = $header;
}
return implode("\n", $stored_headers);
}
#5
Thanks for the explanation -- I'm seeing this as well on my site, also being proxied by nginx.
If I'm understanding things correctly, it looks like this code path has been redone in D7.
Would it be possible to do something about this for D6 sites via a module? I've just done some digging around but I don't see if it'd be possible.
#6
Sorry for bumping into old thread, we moved to nginx frontend for some VPS`es too and ran into the same problem. I googled around and found solution to alter apache2 configuration so that it forces HTTP 1.0 headers.
I added following two lines at the end of /etc/apache2/apache2.conf
SetEnv force-response-1.0 1
SetEnv downgrade-1.0 1
This works for nginx proxy as frontend and apache as backend. I hope it helps someone.
Solution found on http://brainstorm.name/blog/nginx-apache-proxy-chunked-encoding-problem.... which is pointing to http://www.lexa.ru/nginx-ru/msg25234.html
#7
#8
I'm having the same problem on two different sites. This was puzzling the heck out of me... and it only appears to the end user in Internet Explorer (the characters show up before the opening tag). Consider this a subscribe :-/
#9
Here's a quick patch to implement the code listed in #4 above.
#10
subscribe
#11
#6 worked for us. :) Only took about 3 hrs to sort it out.
Thank you, Thank you, Thank you
#12
+1 on #6
#13
Why wouldn't the patch be to change this line:
drupal_set_header('HTTP/1.1 403 Forbidden');
to this one:
drupal_set_header('HTTP/1.0 403 Forbidden');
for nginx - as it needs to have HTTP/1.0 ?
It seems to work fine with that fix in...
#14
OMG, Think that's not a bad way. Why ignored?
#15
basically, moving to pressflow fixes this issue. it's all about drupal < 7 headers.
#16
This appears to be fixed in 6.x-dev, rather than use patch in #4, the offending drupal_set_header() calls in common.inc were replaced like so:
<?phpfunction drupal_access_denied() {
- drupal_set_header('HTTP/1.1 403 Forbidden');
+ drupal_set_header($_SERVER['SERVER_PROTOCOL'] . ' 403 Forbidden');
?>
This requires you to make sure your server is set up to serve HTTP/1.0 for nginx.
#6 gave sample to do this but on our config we needed to add the following to drupal vhosts(http/https):
SetEnv force-response-1.0SetEnv downgrade-1.0
(note to the lack of trailing '1' from #6)
also, it appears ctools.module has a similar issue ctools_shutdown_handler():
header('HTTP1.1 200 OK');, but havn't yet to run into an issue with it yet.#17
The last submitted patch, drupal6-n355170.patch, failed testing.
#18
No patches required, fix is already in core.
The rest of issue is server config.
#19
Automatically closed -- issue fixed for 2 weeks with no activity.