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

On Wed, 19 Aug 2009 14:25:09 -0400, Jonas Sicking <jonas@sicking.cc> wrote:

> 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 :) ).

Understdood.

> 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.

Ah, understood. I think I could work around that by checking responseXML  
to see if it's right. If it's not, perhaps I could manually dispatch an  
'error', if there's a way to manually, create and init a progress event so  
that you can dispatch it. Will play with that.

Thanks

-- 
Michael

Received on Wednesday, 19 August 2009 19:18:46 UTC