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.

#3 ajax_example_http_error_0.tgz4.06 KBrfay
error_0.png11.23 KBrfay
Members fund testing for the Drupal project. Drupal Association Learn more


katbailey’s picture

Following 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)

bleen’s picture


rfay’s picture

To 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

rfay’s picture

This 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
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.

rfay’s picture

If 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.

bleen’s picture

crifi’s picture

This 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!

ponticlaro’s picture

I 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:
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 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

rfay’s picture

Version: 7.x-dev » 8.x-dev

This 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

rfay’s picture