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.
On Nov 13, 2007 12:47 AM, tbeck <tb...@whalespine.org> wrote:
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.
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
On Nov 13, 3:29 am, tbeck <tb...@whalespine.org> wrote:
> 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.
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 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".
> 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:
> 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".
> 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'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?
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:
> > 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'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?
> - 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
> 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.
> > 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.
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?
- 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
|
