drupal.js has horrible handling of status code 0, which normally means that an ajax request has been aborted.

This tiny patch changes the wording to give appropriate information so that in the future perhaps a few of these can be resolved.

What happens: There are literally dozens of open issues that say "HTTP error 0 occurred". However, there are few of these that get resolved because this information is completely inadequate and usually results from an aborted AJAX request, so it's completely invisible.

What I expect: The popup should at least provide the available information so the issue can (perhaps) be debugged.

What happens instead: Nothing but a dialog box that says "HTTP Error 0 occurred".

Let's try to get this in before string freeze.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rfay’s picture

Status: Active » Needs review
rfay’s picture

Issue tags: +ui-text

tagging with for string cleanup/string freeze.

donquixote’s picture

subscribe.
I'm currently not having the error (fixed for me with the new version of jquery.form.js), but I will test your patch when it occurs again.

rfay’s picture

Here's what the new dialog box looks like:

rfay’s picture

FileSize
1.3 KB

You probably need to know how to create this error so you can review the patch.

Here's how:

Install the attached module (ajax_bug_demos).

Go to the menu item that says "AJAX Bugs: Non-AJAX submit" (path: non_ajax_submit_delay). Change the select. Before the AJAX action completes, click "submit". This particular demonstration has a 2 second sleep in the callback, giving you time to demonstrate the abort() situation.

donquixote’s picture

I think this should be more end-user friendly if you really want to release it. A friendly message followed by a developer-oriented message after a linebreak.

I assume the alert is fired before any ajax response is received, am I correct? If so, the text needs to be more clear about this. And, in the other case it should say "malformed ajax response".

rfay’s picture

Thanks, @donquixote. Unfortunately there is no ability to do a line break in Drupal.t(). It turns everything into HTML, which comes out as
in a popup.

"I assume the alert is fired before any ajax response is received, am I correct? If so, the text needs to be more clear about this. And, in the other case it should say "malformed ajax response"."

The alert is fired as a result of an *aborted* ajax response (one for which abort() was called). No information will be there, no information is returned in the cases I've studied. The response is not malformed.

Can you propose error text in this case? The firefox code that has caused us all this pain is here: http://hg.mozilla.org/mozilla-central/rev/151522b6da28. Basically, if the connection errored before we got any data back AT ALL, we get error 0. The only case of erroring I've studied is as a result of abort().

Give me an idea of what you'd like to see and I'll roll it.

donquixote’s picture

Linebreaks:
Work with HTML first, then google for br2nl and be creative :)

Message:

Error.

The AJAX request was stopped by a call to abort(), while waiting for a response.
Path: ...
readyState: ...
...

If I knew more about the error I could write a better text. Very useful to know would be what is calling abort() and why.

EDIT:
Maybe you can throw an exception and look at the backtrace of the abort() call?

rfay’s picture

OK, here's a re-roll per your suggestions (attached).

This one removes the line that was turning my \n's into <br /> inappropriately. Don't know where that came from, but it was backwards.

BTW: In the case I'm studying (the one demonstrated by the module in #5), the abort() is generated by the submit, I believe by an onSubmit() handler, but I don't completely understand it. There's lots of info out there though on the "status 0" response in the abort() case. In this case, I don't believe that the error is even an error. However, if we can get more information for debugging these issues, perhaps we can get to the happy situation where this only appears when there's really an error!

And the new error message looks like this:

katbailey’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
933 bytes

Looks good - I just removed the trailing comma from the array of parameters as we don't do that in JavaScript.

rfay’s picture

Wow, thanks and good eye, katbailey. I hate what the trailing comma syndrome does to IE.

rfay’s picture

webchick expressed some concern that this is too much information. I want to make sure that everybody knows what our *current* dialog box looks like (below). The current message is incorrect (it's not an HTTP error at all), a misdirection, and provides no debugging information at all.

So what we're trying to do here is go a step forward so that we can debug some of these problems. Because of string freeze, this is probably our one chance to be able to do this. I do believe that in D8 we can do something much better - getting the message to watchdog. But I doubt we can get that in now.

Just so you have something to compare against, here is the *current* wrong and ugly dialog box.

rfay’s picture

I just noticed that the link to the open issues on "HTTP Error 0" in the intro to this issue is somehow broken, so here it is again:

There are 55 open issues mentioning this, and many, many more that just faded away after not getting resolved.

In general, this is a firefox and firefox-derived browser issue, as far as I can tell, as some Firefox developer decided to add a status code of 0 without providing additional information. Again, I'm hoping that we can start to gather more information by just putting in this purely informational patch.

RobLoach’s picture

What if we just said:

An AJAX request ending abnormally resulted in an error.
Path: @uri

This is the gist of the rest of the error responses. Doing a Google search for "HTTP error 0" results in mostly stuff regarding Drupal. So cleaning this up a bit definitely is a priority.

rfay’s picture

I think the readyState is the key piece of information we're looking for. In the cases I've studied statusText and responseText are always empty.

It's my suspicion that any of these errors in readyState 4 can just be ignored. I know that's what you get when an AJAX request is aborted. I just don't know if that's all the cases.

A huge number of these are harmless non-error cases, which could actually be ignored instead of putting a big ugly dialog box in front of people.

webchick’s picture

Status: Reviewed & tested by the community » Needs work

Well... While we normally don't do overly verbose debugging code in core like this, it's true that printing out more stuff here is preferable to a vague error that's meaningless. Randy also said on IRC that IE 6 reports JS errors in a similar way, so users may have seen something like this before. So I'm ok with this patch.

However, the error looks as though it's formatted wrong to me... everything's all smooshed together (i.e. "status:0" rather than "status: 0" I also don't get why everything but Path starts with a lowercase letter. Reading the line also gives me a complete headache, and I can't really fathom handing a string to a translator with all those hard-coded \ns in it. Is that just how it has to be done here?

It also seems from reading the patch file that this formatting creates inconsinstency in reporting with the line above ("Drupal.t("An error occurred. \nPath: @uri\n(no information available).", {'@uri': uri });" -- which btw looks like an even more useless error... :P). Probably makes sense to make them both consistent?

rfay’s picture

@webchick, I'm a sucker for anybody that wants to improve instrumentation.

This patch rewrites Drupal.ajaxError() so that all the errors are handled the same way, and quite a bit prettified. If we don't have any information, we don't output it. If we do have information and it can be made prettier (as in responseText) we do. The majority of these errors don't occur often, although when they do it's good to have the information.

I looked at the results on 0, 403, 404, and 500 errors and they look pretty consistent across IE6/IE7/IE8/Firefox/Chrome. Several of the screenshots are attached.

AjaxError.403.firefox.png

Ajax.Error_.0.firefox.png

rfay’s picture

This is the exact same patch with a couple of whitespace issues fixed.

katbailey’s picture

Status: Needs review » Reviewed & tested by the community

OK, so I know I already RTBC'd the original version but this is certainly way better. Tested with both types of ajax error and the messages are helpful and succinct. We need this.

RobLoach’s picture

The good thing about this is that we can override how errors are presented. If we want to, for example, display a jQuery UI dialog box instead, then we could just change the function of Drupal.ajaxError. This status text is much more helpful then what it was before, so I'm in strong support of this.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Awesome, thanks. This looks vastly improved.

Committed to HEAD!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

naught101’s picture

Version: 7.x-dev » 6.x-dev
Status: Closed (fixed) » Patch (to be ported)

Can we get this in drupal 6.x too?

rfay’s picture

This just made it into D7 before the D7 string freeze, but D6 has been string frozen for a a couple of years.... It is possible that the maintainers would consider it, but I'd check with them before putting more effort into it.

naught101’s picture

yeah, ok, It's not a biggie - the patch is fairly easy to apply to 6 anyway, just in a different function, and without the last change.

joelstein’s picture

@naught101: Can you please post the Drupal 6 patch?

marcelboere’s picture

The problem lies solely in running install or update.php from a subdirectory of your server's httpdocs (or whatever) public www directory. In sites/default/settings.php you could specify the $base_url variable, and for what I have noticed, this should be the final url of the site after all kinds of redirections, so the url which stays stable in the address bar while navigating. You should also specify RewriteBase /drupal or whatever subdirectory you have chosen to install the CMS in, in your subdirectory's .htaccess file. (It took me one day and a half to find out that http://www.example.com navigated on http://example.com).

I'm asking assistance for cookie domain settings and base url settings when using the domain module, it has to be made dynamic then.

Also of importance is to notice that in some occasions security settings of drupal root uploads differ from those created in subdirectories. Whilst httpdocs (or whatever public www directory) has 750 protection values, its siblings could have 755. Also check Apache's or server Owner/Group settings. Lots of people manage uploading of modules and core via sftp, so rights could differ.

IE 8 is the only Browser which detects an ajax protection error and there have been efforts on this site to find a more readable explanation of the error. While FireFox is the only Browser that has unlimited debugging facilities for web developers, you should always try all other browsers available at the moment to see if the problem also persists there and if not, search for common problems on drupal.org and react.

Also please all have a look at Drupal 7 as it's available right now. Lots of well known Drupal 6 modules have been integrated now and setting up a new Drupal site from scratch must be a pleasure.

dechengben’s picture

Status: Patch (to be ported) » Needs review
donquixote’s picture

Issue tags: +ajax upload problem
rfay’s picture

Status: Needs review » Patch (to be ported)

@donquixote, not sure how you changed the status, but changing it back. And there is no testing on D6... so requesting a test on a D7 patch against D6 won't be working.

donquixote’s picture

#297035: HTTP error 0
A backport is desperately needed. Does anyone feel like posting a D6 patch?

rfay’s picture

I don't think a change like this can make it into D6, but a patch might be helpful in debugging. The patch here (that got committed to D7) would probably work pretty much as is.

lolmaus’s picture

Subscribing

donquixote’s picture

@rfay,
I think something with newly introduced if/else stuff is more than just a "string change". Or what exactly does "string freeze" mean? If a bug fix requires to introduce new strings (not just change existing ones), isn't that justified? Otherwise, this is just another of a sub-optimal release strategy.

rfay’s picture

@donquixote, I'd be delighted to get this in to D6, and think it would help us overall with working out these problems. I'm not trying to be in the way here.

haclong99’s picture

Hello

I dont know much about ajax and ahah
When i try to apply manually the patch to drupal.js (Drupal 6.19), i don't get the http 0 error anymore (which is obviously good) but now i'm not able to drag and drop to change the weight of items...

Obviously, the patch seems to work but something else has changed.

rfay’s picture

@haclong99, nobody has done a Drupal 6 patch yet, so not sure how you applied this. And this patch doesn't do anything about you *getting* the HTTP error 0 any more, it just does better reporting.

gregoriweb’s picture

Drupal 6 port of the patch in #18 post, my Drupal version is 6.19, not tested in others

webchick’s picture

Status: Patch (to be ported) » Needs review
drupalastic’s picture

apotek’s picture

Why give the user the diagnostic output? The alert should only have the friendly message. The diagnostic output should go to console.log().

alert('friendly message');
if (console !== undefined && console.log !== undefined) {
console.log(diagnostic output);
}

Fabianx’s picture

Issue summary: View changes

Status: Needs review » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.