W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 19 Aug 2009 11:25:09 -0700
Message-ID: <63df84f0908191125m1f3a09dgf7d2aa8570c57b3c@mail.gmail.com>
To: "Michael A. Puls II" <shadow2531@gmail.com>
Cc: arun@mozilla.com, public-webapps@w3.org
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT