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

On Tue, 18 Aug 2009 22:34:47 -0400, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Aug 18, 2009 at 7:13 PM, Michael A. Puls  
> II<shadow2531@gmail.com> wrote:
>>>>> Or is there another reason you end up
>>>>> using file:// urls?
>>>>
>>>> Yes, one thing I'm doing is loading a local xspf file from a local web
>>>> page
>>>> (via a script) and parsing it into an ordered list with registered
>>>> listeners. This page isn't meant to be published on http (but it  
>>>> should
>>>> work
>>>> just the same).
>>>>
>>>> I can do that now with XHR, but it's a mess and error handling isn't  
>>>> good
>>>> enough, nor is it interoperable. DOM3 L&S would be nice, but no one  
>>>> wants
>>>> to
>>>> support it.
>>>
>>> What is different about DOM3 L&S that makes it possible to use here,
>>> but XHR not?
>>
>> Look at the following for example:
>>
>> var parser =
>> document.implementation.createLSParser(document.implementation.MODE_ASYNCHRONOUS
>> , null, null);
>> parser.domConfig.setParameter("error-handler", function(e) {
>>    alert(e.message);
>> });
>> parser.addEventListener("load", function(e) {
>>    alert(e.newDocument);
>> }, false);
>> parser.parseURI("test.xml");
>>
>> 1. It behaves the same whether you're on file:// or http:// in this  
>> case.
>> You don't have to shoehorn the JS or fuss with readyStates and status  
>> codes
>> to make it work with file:
>>
>> 2. Setting an error handler gives you a DOMError object with a message
>> getter that would give info on all the different types of errors from  
>> file
>> not found, to parse error etc.
>>
>> With that said though, if this xhr2 way:
>>
>> var req = new XMLHttpRequest();
>> req.addEventListener("load", function(e) {
>>    alert(this.responseXML);
>> }, false);
>> req.addEventListener("error", function(e) {
>>    alert(e);
>> }, false);
>> req.open("GET", "test.xml");
>> req.send();
>>
>> works where the error handler gives all the different types of errors  
>> and
>> one can just avoid readystatechange, then that might do.
>
> Indeed, that should work per the XHR2 spec. And already does work in
> Firefox 3.5. Try it out!

Yep, did (in latest trunk)

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

> Error handling is complicated as so many things can go wrong, and it's
> hard to find the right level of abstraction. Too detailed errors means
> that some people will check for too few error conditions. Too broad
> errors means that some errors will look the same. Errors can also be
> hard to implement if the underlying libraries doesn't expose the same
> errors as the spec requires.
>
> That said, I'd be all ears for a proposal for how to improve the  
> situation.

O.K. thanks

>>>> Basically, I'm looking for an API that actually supports local,  
>>>> static,
>>>> web-based apps instead of trying to force it into APIs that don't.  
>>>> That's
>>>> why I also proposed
>>>>
>>>> <http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0680.html>,
>>>> just in case the simulating HTTP status code idea wasn't taken well.
>>>
>>> The two things that are different about file:// vs. http:// in gecko I
>>> can think of off the top of my head are:
>>>
>>> 1. Status codes (200, 404, 50x) etc.
>>> 2. Missing http features. CGI isn't supported on local files which
>>> means things like request headers and request methods have no effect.
>>> In fact, no other http methods than GET seems to make sense. Unless
>>> you want to get into the ability to write to the file system, which is
>>> a whole other can of worms.
>>> 3. Security. In http it's (fairly) clear what constitutes a security
>>> context. http://foo.com/ can't access data from http://bar.com/. But
>>> http://foo.com/somefile can read data located at
>>> http://foo.com/otherfile. With file:// that's much less clear. Do you
>>> want file://users/sicking/Desktop/downloaded_files/file.html to be
>>> able to read from file://etc/passwd? How about from
>>> file://users/sicking/Documents/status_report_2009.xls?
>>
>> If it's a file page I create, it's a non-issue. If I downloaded a page  
>> and
>> ran it locally, I would indeed have to worry about it accessing private  
>> data
>> and then tricking me (if it can't to it automatically) into sending it
>> somewhere.
>
> Unfortunately the browser can't tell one from the other. So we always
> assume it's a file you downloaded. As Adam Barth pointed out, this is
> an area that's still very much in flux. Suggestions for how to improve
> things very welcome.

Understood. Thanks

-- 
Michael

Received on Wednesday, 19 August 2009 03:48:49 UTC