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.Bug description: When you use AJAX (simplest example would be autocomplete) in forms, and interrupt the AJAX action, perhaps by clicking another button, you get a popup alert error that says "An HTTP Error 0 occurred".
To recreate the bug a simple technique is just to use Drupal.org. The problem occurs across D6/D7 and all browsers, so the fact that you can see it on D.O is just that that's a good place to demonstrate it. Go to http://drupal.org/project/issues/search/drupal. In the "participants" field type in your userid, but then quickly click the submit button. The example is attached below.
What I expect: The form submission should just take the information it has and interrupt the ajax operation. No error should be displayed.
What I get: An error, widely known in Drupal circles as it's been there for years. But I think we should be able to fix up ajax.js so this doesn't happen.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | ajax_example_http_error_0.tgz | 4.06 KB | rfay |
| error_0.png | 11.23 KB | rfay |
Comments
Comment #1
katbailey CreditAttribution: katbailey commentedFollowing brief irc discussion with te-brian, an upgrade of the jQuery form plugin may be the solution here - see #240777: Attach: An HTTP Error 0 occurred (on file upload)
Comment #2
bleen CreditAttribution: bleen commentedsuperscribe
Comment #3
rfayTo demonstrate the error using the attached module
1. Untar the module.
2. Enable "Ajax Example" module.
3. Go to the "Checkboxes example" page. A menu is provided. (ajax_example/autocheckboxes)
4. Change the select, which triggers an ajax callback. The ajax callback has a 2-second sleep in it.
5. Within 2 seconds, press the submit button.
This demonstrates the slow-response HTTP error 0.
@katbailey suggested that #240777: Attach: An HTTP Error 0 occurred (on file upload) was the issue (needing newer jquery libs) but it doesn't seem to be the case with *this* version of the famous error. http://drupal.org/node/240777#comment-2292168
Comment #4
rfayThis is a Firefox and derivatives *only* error.
It turns out that FF 3+ has decided that status=0 can be returned as the status code for an interrupted (aborted) operation. That's seems to be what's going on here.
The bug discussing this is at https://bugzilla.mozilla.org/show_bug.cgi?id=488605
Per the code shown here this is deliberate: http://hg.mozilla.org/mozilla-central/rev/151522b6da28
So the upshot is that we probably don't have to report an error 0 the way we're currently doing it.
If we get status=0 and readyState=4 on firefox, this means either:
1. A local file was called instead of HTTP:// scheme
or
2. The call was interrupted before any data was received.
I'll roll a patch that attempts to interpret this correctly. In most cases I believe we should just stop processing and ignore.
Comment #5
rfayIf you're following this one please review #646694: AJAX: Terrible reporting of status 0 response from AJAX request ("HTTP Error 0 has occurred") so we can get it in before the string freeze (tomorrow). Getting better information will help us enormously in debugging the dozens of "HTTP Error 0 occurred" issues we have in the queue. That issue has instructions on how to recreate the error (with a sample module) and it's an easy review. If somebody can set it to RTBC today that will be fantastic.
Comment #6
bleen CreditAttribution: bleen commentedComment #7
crifi CreditAttribution: crifi commentedThis problem is maybe caused by a wrong configuration of $base_url and should be prevented by inserting a warning message to the requirements system. Therefore I created a new issue #1046682: Install/Update process fails if $base_url is set to a wrong URL. Please close this bug as a duplicate, if this solves your issue. Thanks!
Comment #8
ponticlaro CreditAttribution: ponticlaro commentedI looked at a ton of forum posts around this issue. Lots recommended various things, but nothing fixed my issue.
Here is what fixed my issue, in case it helps you:
Try to take a look at the "page" that is shown in the error. In your case it is "/filefield/ahah/video/field_video/0"
and in my case it was "/poll/1"
Mine was a JSON document, but inside the document I could see a PHP warning and some garbled text with question marks (characters that could not be displayed). The first thing to do here, so that the JSON can validate is turn off PHP warnings. You can do this by placing:
error_reporting(0);
at the top of your /sites/default/settings.php
This turns off all errors / warnings and is probably a good idea on a production system.
THE OTHER ISSUE IS MUCH MORE IMPORTANT THOUGH -
The garbled characters are also an issue with JSON encoding, but the problem, is these were not in my json response, they had been inserted into my index.php file. Not sure how that happened, except that this project had been on the client's insecure servers for a while before moving to our secured servers, so I traced it back to before that switchover. I removed all of this nonsense code (you will recognize it as gibberish javascript) and bingo, Drupal is back up and running. Check your index.php first, and then maybe look into other files. You can look at any page on your site and scroll through it and you should see the gibberish there as well. Get that out of there!
Good luck
ponticlaro
Comment #9
rfayThis is something we should work out for sure in 8.x.
#8, @ponticlaro, you're definitely right that the error reporting during AJAX responses is a key problem, but it's a different one. I opened an issue for your comment: #1241984: Disable error reporting to screen during AJAX operations
Comment #10
rfayDuplicate of #1232416: Drupal alerts "An AJAX HTTP request terminated abnormally" during normal site operation, confusing site visitors/editors