Ticket 10030 - is Ajax.Request.success() broken?

[tbeck]

Just curious if anyone has a comment on http://dev.rubyonrails.org/ticket/10030

Thanks
Tim

[Mislav Marohnić]

Hmm ... Tobie experimented with return statuses, he might give some clue.

No browser is "violating the spec" because there is no spec for XHR, the document is only a working draft. So, status codes and ready states are not consistent cross-browsers.

[tbeck]

On Nov 12, 6:52 pm, "Mislav Marohnić" <mislav.maroh...@gmail.com>
wrote:

> No browser is "violating the spec" because there is no spec for XHR, the
> document is only a working draft. So, status codes and ready states are not
> consistent cross-browsers.
>

Fair enough. The real issue is that I'm not sure an undefined or 0
status should result in success() returning true, regardless of how
XHR is supposed to work and what the browsers do.

Tim

[Tobie Langel]

Some browsers - I can't remember witch - always return a status of 0
for the file: protocol, others don't return a value at all in that
case, hence this hack.

We're going to be doing more work on Ajax for 1.6.1, but I'm not even
sure there is a real solution ot his issue.

Regards,

Tobie

[Ken Snyder]

Tobie Langel wrote:
> Some browsers - I can't remember witch - always return a status of 0
> for the file: protocol, others don't return a value at all in that
> case, hence this hack.
>
> We're going to be doing more work on Ajax for 1.6.1, but I'm not even
> sure there is a real solution ot his issue.
>
> Regards,
>
> Tobie

I think the trick here is to return a separate status code for files
instead of zero. I believe it is possible to handle all situations.

Here is the result of my research on status codes:

Calling HTTP(S) ajax url
----
Network error scenarios:
FF2 - throws exception
S3 - transport.status == 0
O9 - transport.status == 0
IE6/7 - transport.status == (one of the following)
1223 : Client canceled request
12002: Server timeout
12029: Dropped connection
12030: Dropped connection
12031: Dropped connection
12152: Connection closed by server

Calling file-based ajax url
----
Success: ALL BROWSERS - transport.status == 0
Failure: ALL BROWSERS - transport.status == 0

Note: for network errors on FF 1.x transport.status == 200 and no
exception is thrown so the developer is left to see that the response is
empty to know of a failure. I don't think there is a workaround.

So how can we know the difference between a network error and a
file-based url call?--Both url and location.protocol give clues.

IMHO it is important that we properly route all these codes: file-based
requests should always fire "onSuccess" (unless we can figure out how to
detect a file-based failure) and any of the network error codes should
throw "onException". Right now, we get all sorts of kooky callbacks
such as "on0" and "on12029".

For more info and links to my sources, see the discussion from Sept:
http://groups.google.com/group/prototype-core/browse_thread/thread/1e657fad735d86de/3f25679d7451b816?lnk=gst&q=ken+snyder+ajax#3f25679d7451b816

- Ken Snyder

[Tobie Langel]

Hi Ken,

Thanks for the extended research. That's really helpful!

Could you please clarify what kind of errors FF is throwing ?

Also, could you please kindly advise if Safari 2's behaviour is
consistent with Safari 3 ?

Thanks,

Tobie

> For more info and links to my sources, see the discussion from Sept:http://groups.google.com/group/prototype-core/browse_thread/thread/1e...
>
> - Ken Snyder

[Ken Snyder]

Tobie Langel wrote:
> ...

>
> Could you please clarify what kind of errors FF is throwing ?
>

In the case of a network error, FF2 throws a NS_ERROR_NOT_AVAILABLE
exception any time you get/set XMLHttpRequest.status: the try-catch
block on Prototype 1.6.0 line 1297 is specifically targeted at FF2.
getStatus: function() {
try {
return this.transport.status || 0;
} catch (e) { return 0 }
},

> Also, could you please kindly advise if Safari 2's behaviour is
> consistent with Safari 3 ?
>

I don't have S2 to test, but the following article implies that the
XMLHttpRequest Behavior is the same from S1.2 onwards
http://developer.apple.com/internet/webcontent/xmlhttpreq.html

I'll propose a patch based on these items. I intend to map the
different error code numbers to some custom error codes. The only thing
I'm not sure is how to definitively tell if a file-based request is
made. There doesn't appear to be a protocol property of a
XMLHttpRequest object. I'll have to do some more digging. My current
guess is to check the url for beginning with "file" or "X:\". Any thoughts?

As far as defining success or failure with file-based ajax, I'm guessing
that calling a file should return some type of content on success. It
would be useless to have a file that does nothing and returns no
content. Am I wrong?

- Ken Snyder

[Tobie Langel]

Ken,

Thanks for the update.

Regarding the file protocol issue, that's easy:
window.location.protocol is all you need as per SOP.

Just discussed the other points with Andrew.

To summarize:

- file protocol should always return success.
- previously mentioned non-standard status codes for IE should always
return a status code of 0.
- status code of 0 should trigger an onFailure callback (except
obviously for the file protocol).
- status code of 0 should trigger an on0 callback.
- as the specs don't yet specify that an exception should be raised in
case of a network error, we won't implement that for the moment. So a
status code of 0 will not trigger an onException callback.

You're welcomed to submit a patch.

If not I'll look into it asap.

Regards,

Tobie

On Nov 14, 5:41 pm, Ken Snyder <kendsny...@gmail.com> wrote:
> Tobie Langel wrote:
> > ...
>
> > Could you please clarify what kind of errors FF is throwing ?
>
> In the case of a network error, FF2 throws a NS_ERROR_NOT_AVAILABLE
> exception any time you get/set XMLHttpRequest.status: the try-catch
> block on Prototype 1.6.0 line 1297 is specifically targeted at FF2.
> getStatus: function() {
> try {
> return this.transport.status || 0;
> } catch (e) { return 0 }
>
> },
> > Also, could you please kindly advise if Safari 2's behaviour is
> > consistent with Safari 3 ?
>
> I don't have S2 to test, but the following article implies that the

> XMLHttpRequest Behavior is the same from S1.2 onwardshttp://developer.apple.com/internet/webcontent/xmlhttpreq.html

[Ken Snyder]

Tobie Langel wrote:
> ...

> Regarding the file protocol issue, that's easy:
> window.location.protocol is all you need as per SOP.
>
>

But what about http pages accessing files? I was under the impression
that this is the prime testing situation.

> Just discussed the other points with Andrew.
>
> To summarize:
>
> - file protocol should always return success.
> - previously mentioned non-standard status codes for IE should always
> return a status code of 0.
> - status code of 0 should trigger an onFailure callback (except
> obviously for the file protocol).
> - status code of 0 should trigger an on0 callback.
> - as the specs don't yet specify that an exception should be raised in
> case of a network error, we won't implement that for the moment. So a
> status code of 0 will not trigger an onException callback.
>
> You're welcomed to submit a patch.
>

> ...
Extremely helpful.
One question: We want the file protocol to always trigger onSuccess, but
what status code should it return? 200? I'm assuming we don't want
files to trigger on0

I'll try to submit a patch this week.

- Ken Snyder

[Tobie Langel]

> But what about http pages accessing files? I was under the impression
> that this is the prime testing situation.

That's a violation of SOP. It's just not possible with Ajax. (Else,
imagine how a website could discretely upload most of your hard-
drive's content).

> One question: We want the file protocol to always trigger onSuccess, but
> what status code should it return? 200? I'm assuming we don't want
> files to trigger on0

The file: protocol doesn't have http headers (these are set by a
webserver) so calling on0 (or on200) in that case just doesn't make
any sense.

Best,

Tobie

[Tobie Langel]

Ken, sorry if my last comment sounded a bit harsh - really wasn't my
intention.

Thanks again for your work on this, it really, really helped.

Best,

Tobie

[Ken Snyder]

Tobie Langel wrote:
> Ken, sorry if my last comment sounded a bit harsh - really wasn't my
> intention.
>
> Thanks again for your work on this, it really, really helped.
>
>

Didn't sound harsh to me. :D

Ah, yes, I forgot the same origin policy. location.protocol will make
things simple then. So you're saying files should always fire onSuccess
and not fire any on### callbacks--right?

- Ken

[Ken Snyder]

Patch submitted: http://dev.rubyonrails.org/ticket/10191

- Changed Ajax.Request.respondToReadyState() to fire onSuccess for local
files and on0 + onFailure for network errors
- Changed Ajax.Request.getStatus() to map IE error status codes to 0
- Changed Ajax.Request.success() to define success as a status between
200 and 299

Seems to test fine. Feed back is welcomed.

- Ken Snyder