An HTTP error 0 occured - site/taxonomy/autocomplete/5

Hi,

I am going to have to unhelpfully and painfully close this bug with a "won't fix" -- sorry :-(

I am afraid this has absolutely nothing to do with Drigg. I only got that message if I press the "submit" button WHILE the ajax is still receiving a request.

I noticed that the response you got here was borderline rude... sorry about that. That's not very common.

However, this is completely out of my hands - sorry...

Merc.

Hi,

The only possible explanation I can think of is that you have a very slow internet connection.
When you type tags, the Javascript in the page starts looking up tags for autocompletion. If you type a word, and then WHILE the autocompletion query is happening you press "submit" or "preview", then that Javascript will be interrupted, and will give you that error.

So yes, it is a "bug", but it's totally innocuous and it only happens when you submit the form while autocompletion is happening!

Maybe test that this is indeed the problem, manage to reproduce it, and then submit it as a bug on the Drupal project!

Merc.

I have exactly the same problem with two of my sites. Huge freetagging taxonomy. At some point I just disabled the autocomplete function: http://drupal.org/node/136998#comment-1052317

I get this same error you describe ("An HTTP error 0 occurred /Drupal/?q=filefield/ahah/blog/field_image/0") when trying to upload an image (using ImageField) to a Blog Entry.

This is running on a localhost development machine so network latency is not the cause.

I have to agree with Merc on this one, I think that it is related to the speed at which the autocomplete process accesses the tag database.

It is an annoying bug, you can avoid it by simply giving the field ample time to go thru the tag list and produce some suggestions, which can take up to a minute. That's crazy long for a process on each term, so you can either turn off autocomplete, or just advise your users to wait for suggestions before proceeding and click through the errors when they occur. Neither is a great solution but some explanation is better than none until it can be fixed.

You can also look inside autocomplete.js and ahah.js and comment out any lines starting with 'alert'. This will suppress the error. Why developers would think ANYONE would want an alert error to pop up, I have no idea.

Dave

This seems to work for me, just so you know. No more alert errors of any sort. It does mean that users won't get any feedback when there is a problem, but since a problem just means the autocomplete won't function, I don't see this as a big deal.

Dave

I realize that this is an old post, but I have just encountered this same problem and believe that I have a lead as to why it happens and a method to deal with the problem a little more gracefully than a java alert box which can be terribly annoying, if the function is called repeatedly as is the case with this tool.

The problem seems to be in the parsing of the resultant page. AJAX gets a result page from a uri such as
http://www.mydomain.com/mydrupal/?q=taxonomy/autocomplete/X.

However, what happens if the resultant page contains NON xml elements. For example, if you are hosting on a site the puts a header on every page of your site? I don't see a handler for that situation that can filter our a header. I'll provide an example of the source code from one such call and see if there are any takers on the developers side of this or some pointers on how to deal with this. I haven't had a chance, but I can write enough javascript to come up with a solution if I had the chance to understand just how this file worked.

== source of db.uri on a working site only has the following ==

[ ]

== source of db.uri on a site with trouble has the following ==

[  ]</iframe></noscript></object></layer></span></div></table></body></html><!-- adsok -->
<script language='javascript' src='https://a12.alphagodaddy.com/hosting_ads/gd01.js'></script>

It returns the following java alert when called from within the autocomplete.js

"The page at (my website) says:
An error occurred.
http://www.mydomain.com/mydrupal/?q=taxonomy/autocomplete/4
(no information available)

So, any takers? Could the extra information listed in the source be causing Ajax some heartburn?

Hi,

I think it's *great* that you are looking into this problem that is bothering a lot of projects. But, I really think it's in the wrong spot -- this is a Drupal issue, not a Drigg issue.

I encourage you to *please* submit your ideas and possibly patches against the "Drupal" project, so that lots of skilled people can actually chip in and get it fixed for _every_ module!

Merc.

Oh. I promised a more graceful way to handle the error without disabling the feature entirely.

Open autocomplete.js find the line that reads: " case 'error':" (roughly line 233). Replace it with the following block:

   case 'error':
         //You may try placing debugging or reporting here, but I haven't had any success with this yet. Alert seems to be the only function call that works, which is probably why it was used, but I'd rather a silent non-critical failure than a host of popup gnats to swat.
	  $(this.input).removeClass('throbbing');
	  break;

Then find the line that reads the following in the same file " error: function (xmlhttp) {"
(roughly line 284). Replace it with the following block:

      error: function (xmlhttp) {
                 //Of course, you could place the error handler here, but* it seemed more logical to use the structure already provided with the setStatus function call. This way it would be more likely to be catchable, since you could also add cases and send a different string for specific error types once identified.
		  db.owner.setStatus('error');

Mercmobily,

Thank you. I will try to find the appropriate place then to post this. I haven't yet found a real solution, but I'm getting better results (no annoying errors and the feature is not entirely disabled).

I've got an idea concernig this Issue. Do you have moved your drupal installation from a demo environnement to a production environement ?

The problem is some times drupal keep in is configuration bad url's from the old website, sometimes the web website is on the same serveur but on a different url so , ajax gives an error like 'can execute an ajax xmlhttprequest to a different domain from the script'...

Try to search in this direction.

I had this problem. It just appeared for no apparent reason. I read all of these comments and others. The puzzling thing was that autocomplete would work fine in Safari but not in Firefox. I suspected it had something to do with my server.

So, I just kept filling in a field (even though the autocomplete error would come up) until I knew that I had a valid value. I clicked submit.
Problem went away.

I do not profess to be any expert on any of this or have any idea for the reasons that caused the problem in the first place, but this low tech solution worked for me.

This could be a lead for someone with the same issue:
http://drupal.org/node/136998#comment-1053169

In my case, I found the problem and solution.

Problem:

I have installed Jquery Update module and when I updated Drupal version I copied all the files inside "misc" folder from "modules/jquery_update" to original (in root) "misc" folder.

Solution:

I restored original "misc" folder. After, I copied *only" the jquery.js file from "modules/jquery_update" to "misc".

I found this problem - when implementing views on my production site after it being perfectly OK on my localhost test system (xampp and another wamp!). Turns out in my case that it was an error in the general ajax (by which I mean ahah!) mechanism caused by my base_url being specified as http://domain.com within the setting.php file, but my .htacess redirecting http://domain.com to http://www.domain.com -ie htaccess was adding the www, but the ajax was confused by it. Changing my base_url to include the www fixed it for me! Hooray.

Hope this helps.

Hamish

Not a Drigg issue for me as I don't use Drigg yet. The error console in Firefox indicated that the problem was a keyup or keydown issue with charCode. So I figured it must be some Javascript issue with me, as it wasn't the issue mentioned in #19 for me. I am wondering if I forgot to update my jquery_update. I reinstalled jquery_update but it was not until I selected 6100 in the update.php that my problems went away. So, keeping my fingers crossed, but this seems to be working for me. Also, I had to refresh the browser after the udpate. Hope that helps someone. It is an annoying problem. Although, I must say, the alerts did not prevent the input of information, just the autocomplete dropdown box.

http://webnewcastle.com/article/problems-http-0-ahah-errors-forms

Thanks jasenward. Your solution in #13 works a breeze. Somehow it seems to have got lost in the discussions.

For those experiencing this issue:
Firstly, it is not related to Drigg (infact, I encountered in the simplest of free tag taxonomy implementations), but I am posting the information here as the thread has matured well here, so any stumblers like me will find it useful.

I was initially able to resolve the issue by implementing squeezebox_huf's solution (#19), but then found myself in a situation where if the page was accessed by a URL that did not have the "www" part, then the error was resurfacing. Unfortunately, my hosting company does not provide me access to the .htaccess to add "www" to all URLs. The solution in #13 came in handy.

Just need to remember not to overwrite the autocomplete.js file during future upgrades of Drupal ;)

p.s. for any Drupal newbies like me, the autocomplete.js is under the "misc" folder under Drupal root

Change the following in settings.php fixed it for me...

Comment out $base_url...

# $base_url = 'http://www.mysite.com';  // NO trailing slash!

Uncomment and add wildcard "*." to $cookie_domain...

$cookie_domain = '*.mysite.com';

#23 worked for me thanks!

#19 Led me in the right direction -

My .htaccess was set up to redirect http://www.mydomain.com to http://mydomain.com

My $base_url in settings.php was set to http://www.mydomain.com

switched $base_url to http://mydomain.com and it fixed the problem

#23 did it for me too! Just gotta make sure the domains are consistent in the .htaccess & settings file.

As #23 was not feasible for me because I had two very different domains pointing to the same site, I redirected all sites to the one defined in $base_url through redirect inside .htaccess.

Thanks!

Thanks #20 solved my problem...!!!

I know this is a bit old of a thread, but I thought I would post to see if any of you found the actual culprit of the problem. As the maintainer posted, this is not an issue with this module, but with Drupal itself or the Content Taxonomy's module autocomplete feature.

I have the same symptoms, basically I get a popup error with every character I type. And the error says:

An HTTP error 0 occured.
http://www.mywebsite.com/content_taxonomy/autocomplete/field_keywords

I found that if I flush all the caches when I notice this and then reopen the page to edit, the issue goes away. It works okay until the next time I happens. So it seems something to do with the module and caching. No idea how to fix it. If I don't get any responses here, I think I will just setup a shell script to run a Drush command to clear all caches on my site once a day. That way if it starts to happen, the script should clean it up and I don't have to worry about it.