Re: HTTP status code equivalents for file:// operations - compat with xhr

On Tue, Aug 18, 2009 at 8:48 PM, Michael A. Puls II<shadow2531@gmail.com> wrote:
>>> But, it seems the error progress event doesn't give any error info.
>>
>> Well, it does give error information, but in the cryptic form of
>> event.target.status=200 meaning ok, a null event.target.responseXML
>> meaning there was a parse error, etc. Far from optimal I agree.
>
> That doesn't seem to work right. For a parse error for example, 'load' still
> fires and 'error' doesn't. responseXML isn't null (in Safari it is though)
> and you still get the old <parsererror> for a documentElement. (I know how
> to check for the parsererror namespace)
>
> For file: situations where 'error' does fire, it seems that e.status is 0,
> which means something went wrong, but it's not very revealing.

Indeed, I'm sure there are bugs aplenty here. But that's more due to
buggy implementations than shortcomings in the specs. Best way to get
movement there is to file bugs with testcases (well, even better would
be to attach patches as well :) ).

However note that I'm not sure that failing to parse should fire an
error event. For someone only caring about responseText things loaded
just fine. (I think I actually changed firefox from what you describe
to what I describe sometime after Firefox 2, for this very reason).
The "XML" part of the name "XMLHttpRequest" was never very true.

/ Jonas

Received on Wednesday, 19 August 2009 18:26:08 UTC