Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.How to reproduce this bug?
Set the $base_url to this URL:
$base_url = 'http://www.example.com';
Redirect all request to www.example.com to example.com within the .htaccess file:
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ http://%1%{REQUEST_URI} [L,R=301]
With a pending database update call as UID 1 the update page http://example.com/update.php
You will see AJAX and database errors (more see bug list below), because the base_url is wrong and AJAX requests are answered with HTTP code 301.
References
This bug was reported several times with the same cause:
#463626: array_pop(): The argument should be an array in update.php on line 314
#1012972: Upgrade from 6.20 to 7-rc4 fails on missing and non-updated tables.
#1011618: RC4: Installation frozen at Install Profile
#470292: Warning should be set if $base_url isn't the same as $_SERVER['SERVER_NAME']
#249799: An unrecoverable error has occurred
#610314: Permanent error during database update: An HTTP error 404 occurred. http://mysite/update.php?id=6&op=do
#347753: Ajax returned as new page when updating a field
How to patch this?
In my opinion drupal should detect if the base_url URL is not reachable (see my patch) on install, update and runtime. My patch is not a good solution if drupal can't call http requests (see requirement test in system.install). But I don't know how to bound the patch in all cases (When I proof for $phase == 'update' the updater doesn't proof my test?). Please evolve my patch. Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| test_base_url_wrong.patch | 1.04 KB | crifi | |
Comments
Comment #1
crifi CreditAttribution: crifi commentedI have now closed all dependent bug reports as duplicate or leaved a comment there. I hope this will help to focus our work.
Comment #2
Vacilando CreditAttribution: Vacilando commentedSubscribing.
Comment #3
parasox CreditAttribution: parasox commentedIf this indeed resolves #297035: HTTP error 0 you will have achieved nirvana.
Comment #4
crifi CreditAttribution: crifi commentedAdditional Information: How to reproduce this bug?
You can always reproduce this bug, if you have an AJAX request (by Installer/updater, CTools,...) and the $base_url in your settings.php is not reachable. AJAX requests are handled by the base_url and hence if this URL is not reachable there occurs HTTP errors.
So a new example to my first one: You have a HTTPS-only site https://example.com (by VirtualHost or Redirecting) and pointing $base_url to the HTTP URL http://example.com
Am I affected?
So if you have a similar issue, please proof that it's not caused by a non-reachable $base_url configuration! You can do so, by pointing your browser to the exact $base_url or look at firebug/wireshark when doing an AJAX request.
Comment #5
crifi CreditAttribution: crifi commentedMore References
Here are some more references which are affected in my opinion:
#706094: Update.php will not run correctly
#653138: Needs some work
#585250: Error when doing update.php
#400756: Permanent error during database update: An HTTP error 404 occurred. http://mysite/update.php?id=6&op=do
Comment #6
As If CreditAttribution: As If commented@parasox - Don't hold your breath. crifi has obviously not read the entire thread over there. The HTTP error 0 message is caused by a wide variety of conditions. It is often intermittent, often browser-based, sometimes can be fixed by increasing memory limit, sometimes can be fixed by removing a module... etc... i.e., most of those errors have nothing to do with the base url.
Comment #7
crifi CreditAttribution: crifi commentedI have never asserted that my solution works for all issues and comments there. But many issue queues are a mixture of different causes with similar symptoms since AJAX errors are hard to distinguish. Issues I was sure that the cause is only a false $base_url, I closed the bug as duplicate, in other cases I leave it open and make just a hint that it can be caused by this one here. Please proof if this is the real cause in your issues or parts of the comments, otherwise this is a dead end.
This is also an argument to close this bug: If we have a detection method for a false set $base_url config, we can differ this problem from others.
Comment #8
catchNot a major bug, if $base_url is wrong in settings.php, then it is wrong, and you shouldn't expect everything to work. Adding some error detection, if that can be done without introducing overhead, might be nice, so moving to a task.
Comment #9
llribas CreditAttribution: llribas commentedin my case, after all validations and suggestions about base_url, still not working.
At the end, using MS Iexplorer instead of firefox, it worked fine
Comment #10
crifi CreditAttribution: crifi commentedIn my opinion this is a bug, because drupal seems configured well and shows the whole site. It only produces misleading AJAX error messages, so that the admin presume that there is a specific AJAX problem. It isn't obvious that there is a misconfiguration in the configuration file.
This also follows your documentation of a bug report "Incorrect or misleading user interface text" (http://drupal.org/node/1181250).
I hope you can agree with me.
Comment #11
sunEvery custom value in settings.php is custom PHP code, and Drupal cannot validate that your custom PHP code is correct. Drupal core generally does not babysit broken code.
The
$base_urlsetting is optional and not set by default. If you need to set it, then you need to ensure that the custom value is correct.Comment #12
crifi CreditAttribution: crifi commentedI am still convinced that there is a problem when the software displays an incorrect error cause. Sorry!