Ruby on Rails | Screencasts | Download | Documentation | Weblog | Community | Source

Ticket #4267 (new defect)

Opened 2 years ago

Last modified 1 year ago

[PATCH] Exception thrown if web server is down for AJAX requests

Reported by: Blair Zajac <blair@orcaware.com> Assigned to: Tobie
Priority: normal Milestone:
Component: Prototype Version: 1.1.0
Severity: major Keywords: Ajax status
Cc: mislav

Description

Using Firefox and Prototype with an AJAX Rails app, the onFailure function argument will not be called if there is no web server listening on the port that the AJAX call is being made to. You have to use the onException call, but the exception is being called because the transport.status does not exist, and the Mozilla JavaScript engine throws an exception:

The way to reproduce this problem yourself is to apply this patch, reload an AJAX Rails app in Firefox, then kill the server and then try an AJAX call: 

Index: public/javascripts/prototype.js
===================================================================
--- public/javascripts/prototype.js     (revision 103805)
+++ public/javascripts/prototype.js     (working copy)
@@ -714,6 +714,12 @@
     var transport = this.transport, json = this.evalJSON();

     if (event == 'Complete') {
+        try {
+            alert('Message 1 ' + this.transport);
+            alert('Message 2 ' + this.transport.status);
+        } catch (e) {
+            alert('Exception caught: ' + e.name + ' ' + e.message);
+        }
       try {
         (this.options['on' + this.transport.status]
          || this.options['on' + (this.responseIsSuccess() ? 'Success' : 'Failure')]

The first alert will succeed, but the next alert will not be called and the alert in the catch block will be used.

See

http://radio.javaranch.com/pascarello/2006/02/07/1139345471027.html

for more information.

It would be nice if there was a way to catch this failure case so you can use onFailure when the web server is down instead of onException, as this error seems to be Firefox specific.

Regards, Blair

Attachments

prototype-diff.txt (1.5 kB) - added by blair on 03/16/06 21:37:29.
First pass at a patch
prototype-diff2.txt (1.5 kB) - added by blair on 03/16/06 21:48:46.
Better version that caches tries to get a copy of this.transport.status once and catches that

Change History

03/16/06 21:15:51 changed by blair

BTW, this is with Firefox 1.0.7 on Centos 4.1.

03/16/06 21:37:29 changed by blair

  • attachment prototype-diff.txt added.

First pass at a patch

03/16/06 21:38:58 changed by blair

Just attached a first patch to work around the problem.

Ideally, there would be a nice and safe way to get the transport.status value without using a try/catch block, but I'm not a JavaScript expert to determine the best way of accomplishing this.

Regards, Blair

03/16/06 21:48:46 changed by blair

  • attachment prototype-diff2.txt added.

Better version that caches tries to get a copy of this.transport.status once and catches that

03/16/06 21:57:29 changed by blair

  • summary changed from Exception thrown if web server is down for AJAX requests to [PATCH] Exception thrown if web server is down for AJAX requests.

Add PATCH to summary.

03/31/06 21:32:39 changed by blair

BTW, I was looking at Yahoo's new code to see how they handle this issue in Firefox and they have similar code to handle this case. From connection.js from:

http://developer.yahoo.com/yui/downloads/connection.zip 

        handleTransactionResponse:function(o, callback)
        {
                var httpStatus;
                var responseObject;

                try{
                        httpStatus = o.conn.status;
                }
                catch(e){
                        // 13030 is the custom code to indicate the condition -- in Mozilla/FF --
                        // when the o object's status and statusText properties are
                        // unavailable, and a query attempt throws an exception.
                        httpStatus = 13030;
                }

Yahoo's code doesn't have an onException case however, but they do take care to create a new response object using as much information as possible, setting the status to 0 if an an odd status shows up.

Interestingly, they also handle odd status cases returned by IE, such as 12002, 12029, etc.

Regards, Blair

03/31/06 21:33:10 changed by blair

  • version changed from 1.0.0 to 1.1.0.

Bump to 1.1.0.

11/04/06 19:24:57 changed by mislav

  • cc set to mislav.
  • keywords set to Ajax status.
  • severity changed from normal to major.

I'm working on a big Ajax patch (#6366). This browser issue is pretty nasty, though, and should require a separate fix. I'll see if I can whip something up

05/09/07 07:52:10 changed by Tobie

  • owner changed from sam to Tobie.