About

Nodeta is a software development company that focuses on web software. We employ a highly agile and effective process. We have worked both on light independent projects and in the environment of large global enterprises.

Our Products

Flowdock

Streamline your team's tasks, feeds and communication. Organize with tags. Sign up for beta!


APIdock

APIdock provides a rich and usable interface for searching, perusing and improving the documentation of projects that are included in the app.

Categories
Archives
-->

Undefined success with Prototype

Mikael Roos April 15th, 2008

I noticed something really strange in the Prototype API today after a fellow developer came smirking to ask me why an export action seemed to quickly success after he had dropped the whole server. I tried to reproduce the situation and surely enough, the onSuccess callback ran when there effectively was no response. I immediately perused the Prototype API documentation and to my amazement read this description for the onSuccess callback:

Invoked when a request completes and its status code is undefined or belongs in the 2xy family. This is skipped if a code-specific callback is defined, and happens before

onComplete

.

Did you notice that? “Invoked when a request completes and its status code is undefined…” What on earth!? After some googling, I found out that this is no new discovery and that there’s more to this problem than you’d think.

Different browsers handle the situation differently, and so, what eventually ends up in the status field of the response object, varies greatly depending on the browser and the protocol. Since there is no standard XMLHTTPRequest, there is no standard behavior for a browser regarding what should be passed to the JavaScript response object. In the olden golden days of standard HTTP requests there of course is no problem because there just is no response.

Apparently, when a network problem occurs and no actual response is received, Firefox and Opera (most versions) pass an undefined status with status code 0, IE passes its own proprietary status codes in the 1000-range and Webkit/Safari, in addition to the occasional status code of -1004 (!), also passes a status code of zero. Other problems are brought on by the use of file protocol.

There has been a few suggested patches (1) (2) (3) (4), and the status quo will hopefully change soon.

In the meantime, you can solve the problem in at least these ways:

  1. Use the on0 callback (that’s “on”-zero) to separately handle the cases when the browser passes a status code of zero to the AJAX Response object. The fired on0 will block the onSuccess from firing.
  2. Forget all the different completion-related onXXXX callbacks and simply only use the onComplete and manually check if the status code pleases you – something along the lines of this:
    new Ajax.Request("/path", {
      onComplete: function(response) {
        if (response.status==200)
          alert('Very successful!');
        else
          alert('Far less successful');
      }
    });