Posted by SeanBannister on October 11, 2009 at 11:41am
| Project: | 404 Blocks |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Just noticed on the project page of this module it says :
* Unless you have configured a "Default 404 (not found) page" on admin/settings/error-reporting.
However I've noticed on my site even if I do set a default 404 page blocks still don't show. I'm thinking this might be a mistake in the project page?
Thanks for this module, really handy.
Comments
#1
Apparently the headers being checked don't quite match anymore.
#2
+1
Tested with Apache and CentOS 5.2.
#3
Hmm… this is the second report of the headers not matching. However, Drupal hard-codes the header, so I'm really confused how you guys are seeing a different header string then what Drupal is putting into drupal_get_headers(). :-\
On 404, drupal sets this header inside drupal_not_found(). http://api.drupal.org/api/function/drupal_not_found/6
What headers are you guys seeing?
See also #371069: Stop hardcoding the HTTP protocol version
#4
In
#2
dema502 - February 11, 2009 - 00:24
I use drupal+apache on backend and ngnix on frontend
-----
He is using an ngnix as a proxy/balancer
In my case I have an HAProxy for balancing load that acts as a proxy.
So it is possible that when you have a proxy the headers are sanitized.
Have the other guys in this issue some balancer/proxy/cache... in front of drupal?
#5
My site is returning the following 404 header:
Content-Type: text/html; charset=utf-8 HTTP/1.1 404 Not Found
edit: I've made the changes myself
if (strpos(drupal_get_headers(), 'HTTP/1.1 404 Not Found') !== FALSE|| strpos(drupal_get_headers(), 'Content-Type: text/html; charset=utf-8 HTTP/1.1 404 Not Found') !== FALSE)
while I can confirm that the if statement returns true but $vars['show_blocks'] = TRUE; doesn't display my right region.
Am I missing something?
#6
+1, the headers were not matching for me. I'm using Pressflow, not sure if that matters or not. I know they do a bit of header manipulation to make things behave properly for reverse proxies.
Here's my fix.
function blocks404_preprocess_show_blocks(&$vars, $hook) {$headers = drupal_get_headers();
if ((strpos($headers, 'HTTP/1.1 404 Not Found') !== FALSE) || strpos($headers, '404 Not Found') !== FALSE) {
// Show all regions.
$vars['show_blocks'] = TRUE;
}
}
#7
Ooooh. You're using Pressflow. Hmm… I wonder if they've patched that part of Drupal that I'm relying on. Is Drupal core's hard-coded value in drupal_not_found() is not the same as Pressflow's drupal_not_found()?
Hmm… nope. Pressflow still hard-codes the string I'm looking for in this module.
drupal_set_header('HTTP/1.1 404 Not Found');See http://bazaar.launchpad.net/~pressflow/pressflow/6/annotate/head:/includ...AHA! Pressflow's drupal_set_header() is hacked to strip out the first 9 characters of any header starting with "HTTP/1.". See http://bazaar.launchpad.net/~pressflow/pressflow/6/annotate/head:/includ...
Okay. Now that I finally understand what is going on, I have no problem committing a fix for it!
#8
Committed the patch by mikey_p. Thanks for all the help, everyone! I really didn't understand what was going on until Robert said "I'm using Pressflow, not sure if that matters or not". It sure did matter! :-D
#9
Had same issue here using Nginx proxy which uses a HTTP 1.0 client.
if (strpos(drupal_get_headers(), '404 Not Found') !== FALSE) {fixed it.
DT
#10
Automatically closed -- issue fixed for 2 weeks with no activity.