I ran across what I believe to be a bug in Prototype last week. It has to do with the Ajax.Request.success() method which indicates if a given ajax request was successful or not, based on the http status code.
I’m currently developing against v1.5.1.1 and in that version of Prototype the success function looks like this.
success: function() { return !this.transport.status || (this.transport.status >= 200 && this.transport.status < 300); },
I'm particularly concerned about the first operand for the || operator. What this says is that if the transport has a status of 0 or undefined, the request is successful. That doesn't sound right to me. If the transport status is not available then the request should be a failure. That seems to me the only logical way to handle an unknown status situation. I'm not sure if there is some other thinking behind this. I've so far got no response to the ticket I've opened on the prototype trac installation.
Here's what I've patched my local copy of prototype 1.5.1.1 with:
success: function() { return this.transport.status && (this.transport.status >= 200 && this.transport.status < 300); },
The function changed slightly in 1.6, but it still has the same issue.
For what it's worth, I ran across this because Opera appears to violate the XMLHttpRequest specification. Specifically, the spec states with respect to the 'status' function:
On getting, if available, it must return the HTTP status code sent by the server (typically 200 for a successful request). Otherwise, if not available, the user agent must raise an INVALID_STATE_ERR exception.
In at least one case, when the status is 504, Opera returns transport.status as 0. You can imagine how much my javascript code flipped out when the ajax request was reported as successful, but there was no response data.
Like I said above, I've opened a ticket on the prototype trac. Hopefully it will be addressed or explained to me at some point. See http://dev.rubyonrails.org/ticket/10030.
4 Comments
Why not:
return this.transport.status && (this.transport.status / 100 == 2);
That should be faster. I’ll do some testing.
Did some profiling with Firebug and your suggestion is 1/3 faster. Of course the average time per call is 0.067 ms, so this is just a teeny gain.
After a discussion on the Prototype Core mailing list, a patch has been submitted to fix up this issue. I gotta say it is a more complete fix than I intended, as it takes care of odd IE error codes and deals with the file:// protocol.