Posted by skizzo on September 16, 2009 at 8:38pm
| Project: | Domain Access |
| Version: | 6.x-2.0-rc9 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I am seeing the following php errors on a test site's night watchdog (although site access is restricted by securesite).
Apart from those, I am not seeing any other DA related UI error when testing the site, and wouldn't know how to reproduce it.
For all errors: Hostname xxx.xxx.xxx.xxx (allocated to ISP in China) and User x-user (my defined anonymous user for domain Id 0)
The same sequence is repeated twice, with Location: http://www.google.com:80 and then with Location: http:///mail.google.com:443
- Cannot use a scalar value as an array in /var/www/drupal/sites/all/modules/domain/domain.module on line 61.
- array_merge() [<a href='function.array-merge'>function.array-merge</a>]: Argument #1 is not an array in
/var/www/drupal/sites/all/modules/domain/domain.module on line 87.
- parse_url(http://) [<a href='function.parse-url'>function.parse-url</a>]: Unable to parse URL in /var/www/drupal/sites/all/modules/domain/domain.module on line 1002.
Comments
#1
I suspect that the $_SERVER['HTTP_HOST'] is not getting read correctly, as these errors should not occur if the module is installed and working correctly.
Line 61: $_domain is initialized as an array in domain.bootstrap.inc, so I wonder where this is getting turned into a string?
Line 87: By this point $_domain['domain_id'] should always resolve to a known host, but domain_lookup() is obviously returning -1 (FALSE), so again, something is off.
Line 1002: This is odd. What is your $base_url value? Are you setting it manually in settings.php? If so, remove that line. You cannot set $base_url when using DA.
This is not something I can replicate, so you have to do a little digging.
Are you getting any other error messages in the UI?
#2
Actually I've encountered all three in my logs as well a few times. From what I've noticed all three occur at the same time and it's awfully close to cron run time in my case.
#3
No other messages in UI, and I didn't notice any adverse effect either; $base_url is not set in my settings.php. As in #2, the event is quite close to cron time (2 minutes ahead). I am using feedapi and cron could trigger connections to Google servers. Access to the system by external users should be inhibited by securesite. HTTPD logs are recording the following associated events:
access_log:211.94.162.151 - - [16/Sep/2009:02:43:14 +0200] "GET http://www.google.com/ HTTP/1.1" 302 - "-" "Mozilla/4.0 (compatibale; MSIE 6.0; windows NT 5.1; sv1)"access_log:211.94.162.151 - - [16/Sep/2009:02:43:14 +0200] "CONNECT www.google.com:80 / HTTP/1.1" 302 - "-" "-"
access_log:211.94.162.151 - - [16/Sep/2009:02:43:14 +0200] "CONNECT mail.google.com:443 / HTTP/1.1" 302 - "-" "-"
access_log:211.94.162.151 - - [16/Sep/2009:02:43:15 +0200] "GET http://www.google.com/ HTTP/1.1" 302 - "-" "Mozilla/4.0 (compatibale; MSIE 6.0; windows NT 5.1; sv1)"
error_log:[Wed Sep 16 02:43:14 2009] [error] [client 211.94.162.151] PHP Warning: Cannot use a scalar value as an array in /var/www/drupal/sites/all/modules/domain/domain.bootstrap.inc on line 58
error_log:[Wed Sep 16 02:43:14 2009] [error] [client 211.94.162.151] PHP Warning: Cannot use a scalar value as an array in /var/www/drupal/sites/all/modules/domain/domain.bootstrap.inc on line 58
#4
Using drupal_http_request()? I wonder what is going on behind the scenes there.
In general, these messages are harmless, if annoying. It looks like some process is bypassing settings.php and the whole domain bootstrap process.
#5
One way these errors can occur is when Apache's "internal dummy connection" inadvertently invokes Drupal (presumably with some server variables missing?). See: http://wiki.apache.org/httpd/InternalDummyConnection
What worked for me in this case was adding the following to Drupal's .htaccess, immediately before the clean-URL rules:
RewriteCond %{REQUEST_METHOD} =OPTIONSRewriteRule .* dummy.html
This isn't a DA bug. Presumably these handicapped Drupal processes would run with or without DA; but DA reports an error because of the missing domain name info. Unfortunately, InternalDummyConnection requests are used by Apache to kill processes that have lingered too long -- which, under some server configs, could be caused by high db volume, so this leads to a vicious circle with the DA errors generating more db queries that stall and then inspire Apache to issue more InternalDummyConnection requests. (I watched this bring a whole site down for a couple of minutes yesterday.)
What would the ideal solution be? My .htaccess fix (which depends on mod_rewrite)? A line in Drupal bootstrap to exit on OPTIONS-method requests?
#6
Well, we can wrap those lines in an !isset or !empty, too.
#7
I can account for some of the issues in domain.module, I think, but that error on line 58 of domain_boostrap.inc makes no sense.
Is it possible the global values are getting reset/erased by your server?
That would explain why $base_url is missing, too.
This patch addresses the fixable issues.
#8
#9
Re: "Is it possible the global values are getting reset/erased by your server?"
don't know, but I guess I would have noticed major problems then. The line 58 warning showed up a couple of more times, then I have not seen it for more than two weeks. I will keep an eye on it and open a separate issue if it shows up again.
#10
I've moved this to it's own issue.
#11
Automatically closed -- issue fixed for 2 weeks with no activity.