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

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?

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

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

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

/ Jonas

Received on Wednesday, 19 August 2009 01:09:26 UTC