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

On Tue, 18 Aug 2009 21:08:25 -0400, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Aug 18, 2009 at 12:39 PM, Michael A. Puls
> II<shadow2531@gmail.com> wrote:
>> On Tue, 18 Aug 2009 15:09:53 -0400, Jonas Sicking <jonas@sicking.cc>  
>> wrote:
>>
>>> On Tue, Aug 18, 2009 at 12:03 PM, Michael A. Puls
>>> II<shadow2531@gmail.com> wrote:
>>>>
>>>> O.K. Thanks. fileadata: wouldn't work then if the user has to choose  
>>>> the
>>>> file.
>>>
>>> Maybe it would help if you started with a use case. What type of thing
>>> are you trying to build?
>>>
>>> Many times when people deal with file:// urls it is because they are
>>> building a website on a local file system, and then at appropriate
>>> times publish that website by copying the local files to a web server.
>>
>> I support that convenience (when dealing with static files) very much.  
>> (And,
>> I don't think think this use case should be dismissed, just in case  
>> anyone
>> thinks that.)
>>
>>> Is that what you are doing?
>>
>> A lot of times, yes. I believe things should work the same between  
>> http: and
>> file: in static (not php etc. of course) cases. They basically do with  
>> DOM3
>> Load and Save.
>
> Ok, so for this use case something simpler than what you proposed in
> the beginning of this thread should be enough. For example the status
> codes 401, 403, 405, 501, 414, 415 does not seem needed. 404 and 200
> seems enough. Or am I missing something?

*Just* 404 and 200 would definitely make things better. But, see below.

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

But, it seems the error progress event doesn't give any error info.

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

With Firefox's security, I'd just make sure not to run any untrusted local  
web pages in directories that contain private stuff.

Working with an evil plug-in might make things harder to lock down.

> 1 seems fixable, 2 and 3 are much much harder.

Thanks

-- 
Michael

Received on Wednesday, 19 August 2009 02:14:28 UTC