On Tue, 18 Aug 2009 22:34:47 -0400, Jonas Sicking <[email protected]> wrote:
On Tue, Aug 18, 2009 at 7:13 PM, Michael A. Puls
II<[email protected]> 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
