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

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!

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

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.

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

/ Jonas

Received on Wednesday, 19 August 2009 02:35:47 UTC