Re: Mass Subscription, and How to Unsubscribe

[Michael A. Puls II]

On 6/11/08, Doug Schepers <[EMAIL PROTECTED]> wrote:
>
>  Hi, Folks-
>
>  If you are reading this email, and wondering how you got added to this
> email list, you were previously subscribed to either WAF
> <[EMAIL PROTECTED]>, WebAPI <[EMAIL PROTECTED]>, or both. Since we
> have merged those groups into the new Web Applications (WebApps) WG, and
> closed down those lists, I subscribed you to the new discussion forum,
>  as a courtesy.
>
>  If you hate being autosubscribed, I don't blame you, and you can blame me.
> I'm honestly very sorry if you didn't want to be added, and it is very easy
> for you to unsubscribe yourself.  You can either send an email to
> <[EMAIL PROTECTED]> with the word "unsubscribe" in the subject,
> or write to me personally and I'll do it manually.
>
>  It is not W3C policy to subscribe people without their prior request, and I
> was explicitly advised by The Power That Be not to do so, but I made a
> judgment call that most of you would rather not miss out on messages of
> interest.  Honestly, it's really very interesting... you should stick
> around.
>
>  So, welcome to the WebApps mailing list!

Thanks for autosubcribing me. It was a good call to do so

-- 
Michael

Re: [NOT] Microsoft's feedback on XHR2

[Michael A. Puls II]

On 6/16/08, Chris Wilson <[EMAIL PROTECTED]> wrote:
>
>  No.
>
>  I understand why you might like to edit our feedback, Ian, but your edit 
> does not, in fact, represent Microsoft's feedback on cross-domain.  What you 
> call "redacting background material" I call "removing principles such that 
> remaining points might seem unprincipled."  The members of the WG (and the 
> public) are welcome to draw their own conclusions from our statements; I am 
> NOT willing to have you be the one who draws their conclusions for them.
>
>  As every email software package I'm aware of can handle HTML and text, and 
> most of them can do an automatic translation between the two of them, I'll 
> ask you again to not editorialize on Microsoft's motives or actions for the 
> group.  Particularly when you are redacting the very principles at issue.

Could you please provide a text/plain *only* message of the feedback
in full for good measure?

Thanks

-- 
Michael

Re: [whatwg] WebIDL and HTML5

[Michael A. Puls II]

On Tue, 26 Aug 2008 23:20:16 -0400, Boris Zbarsky <[EMAIL PROTECTED]> wrote:



Garrett Smith wrote:

I have created a demo which expects that setting textContent to null
will have no effect, as per DOM Core 3.


Except that's not what DOM Core 3 says.  Please do read what it says.  
Carefully:


   On setting, any possible children this node may have are removed
   and, if it the new string is not empty or null, replaced by a
   single Text node containing the string this attribute is set to.

So.  On setting all children are removed.  If the string is not empty or  
null, they are then replaced by a single Text node, etc.  If it's empty  
or null, the kids are removed and that's it.  It would perhaps help to  
write this out as a step-by-step list instead of having a moderately  
complex grammatical structure with a subordinate clause, but the meaning  
is still the same.


As for your test, sounds to me like Firefox and Webkit implement what  
the spec says, and Opera is just buggy here.


Couple examples:

Example 1:
var div = document.createElement("div");
div.textContent = null;

'textContent' takes a DOMString, null is not one, null is toString()ed to  
"null" and the textContent becomes "null".


Example 2:
var div = document.getElementsByTagName("div")[0];
div.style.display = "none";
div.style.display = null;

'display' takes a DOMString, null is not one, null is toString()ed to  
"null" and since "null" is not a valid value for the display property, the  
new declaration is ignored and the display remains at 'none'.


I know Opera differs in these cases compared to Safari and Firefox, but  
from an ECMAScript point of view, Opera does what I expect.


With that said, if that's a behavior of ECMAScript and the DOM spec  
clashes, which one gets priority and in what situations and why?


Although I understand why it might be desired to have null have the same  
effect as "", it seems odd to be so inconsistent across different things  
in the DOM and inconsistent with ECMAScript (which exposes the DOM to  
users, in browsers).


It'd be nice if the behavior was the same for all DOM things taking a  
DOMString. But, since that probably can't happen because of compatibility,  
I guess it would be great to have a way to show each and every special  
case so browsers don't differ and break pages.



--
Michael

Re: [whatwg] WebIDL and HTML5

[Michael A. Puls II]

On Wed, 27 Aug 2008 08:34:03 -0400, Boris Zbarsky <[EMAIL PROTECTED]> wrote:


Michael A. Puls II wrote:

'textContent' takes a DOMString, null is not one


Uh... Except null IS a DOMString according to the DOM specs.  Certainly  
they implicitly treat it as one, and one of the clarifications that  
WebIDL is making is making it clearer that null is a valid DOMString  
value.



null is toString()ed to "null" and the textContent becomes "null".


Except that's not what the spec for textContent says to do.  Please do  
read the spec.  Carefully.


Yes, understood. Those were just my guesses for reasons why Opera does  
what it does.


I know Opera differs in these cases compared to Safari and Firefox, but  
from an ECMAScript point of view, Opera does what I expect.


But it doesn't do what the DOM spec says to do in the textContent case.  
  Sad, but there you are.


Understood.

With that said, if that's a behavior of ECMAScript and the DOM spec  
clashes, which one gets priority and in what situations and why?


The DOM spec gets priority for methods it defines, just like in all  
cases of host objects and methods.  There are no requirements for those  
to follow all sorts of rules that native methods and objects have to  
follow.  See the ECMAScript spec.


O.K. Thanks. That clears it up right there.

Although I understand why it might be desired to have null have the  
same effect as "", it seems odd to be so inconsistent across different  
things in the DOM and inconsistent with ECMAScript (which exposes the  
DOM to users, in browsers).


It _is_ odd.  But it's an established fact of life, and changing that  
behavior is not acceptable at this point.


Understood.

Too bad no one brought all this up back when the DOM specs were being  
written.  Or maybe they did, and the non-ECMAScript users of the DOM  
carried the day on the issue. Again, in other languages the fact that  
null is a string is much more natural than in ECMAScript.


Yes, too bad.

Thanks


--
Michael

Re: [selectors-api] Test Suite Missing tests for Namespace Selectors

[Michael A. Puls II]

On Thu, 12 Mar 2009 10:47:53 -0400, Alexey Proskuryakov  wrote:



12.03.2009, в 17:19, Lachlan Hunt написал(а):


WebKit has a bug with the "|foo" selector.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/28

Opera and Firefox pass



This is actually a difference in createElementNS(null, "p") vs.  
createElementNS("", "p") behavior. I don't know whose bug it is, but in  
Firefox and Opera, empty and null namespace arguments both result in  
null namespace for the created element.


When createElement(null, "p") is used, this test passes in WebKit, too.


I filed  a while ago, which is at least 
one bug that has to do with the null or "" issue.

--
Michael

Using xhr with file://

[Michael A. Puls II]

I think file:// should be a first class citizen when it comes to xhr (local 
page loading local .xml file for example).

However, currently, there are some interoperability problems.

1. XHR doesn't work on local pages in IE. You get "Access is denied".

2. For open("GET", "non-existent.xml"):

Firefox: Throws NS_ERROR_DOM_BAD_URI and .readyState stops at 1.

Safari: Doesn't throw and .readyState stops at 1.

Opera: Doesn't throw and .readyState stops at 4.

3. readyState changes for found local file:

Firefox: 1, 2, 3 ,4 ,1

Opera: 1, 2, 3, 4

Safari: 1, 2, 3, 4

4. status changes inside onreadystaechange for found local file:
try {
alert(this.status);
} catch (err) {
alert(err);
}

Opera: invalid state error, invalid state error, 0, 0

Safari: invalid state error, 0, 0, 0

Firefox: 0, 0, 0, 0, 0

5. In http, you can do if (this.readyState === 4 && this.status === 200). 
However, for file://, you have to do (this.readyState === 4 && (this.status === 
200 || document.location.protocol === "file:") or assume this.status of 0 means 
"file:".

It'd be cool if browsers would match each other (including IE supporting xhr 
for file://) and either throw an exception for file not found like Firefox does 
or simulate http statuses for local files (200 and 404 for example), or some 
combo so a page will work locally and on the server without change.

-- 
Michael

Re: Using xhr with file://

[Michael A. Puls II]

On Thu, Apr 16, 2009 at 10:10 AM, Michael A. Puls II
 wrote:
> I think file:// should be a first class citizen when it comes to xhr (local 
> page loading local .xml file for example).
>
> However, currently, there are some interoperability problems.
>
> 1. XHR doesn't work on local pages in IE. You get "Access is denied".
>
> 2. For open("GET", "non-existent.xml"):
>
> Firefox: Throws NS_ERROR_DOM_BAD_URI and .readyState stops at 1.
>
> Safari: Doesn't throw and .readyState stops at 1.
>
> Opera: Doesn't throw and .readyState stops at 4.
>
> 3. readyState changes for found local file:
>
> Firefox: 1, 2, 3 ,4 ,1
>
> Opera: 1, 2, 3, 4
>
> Safari: 1, 2, 3, 4
>
> 4. status changes inside onreadystaechange for found local file:
> try {
>    alert(this.status);
> } catch (err) {
>    alert(err);
> }
>
> Opera: invalid state error, invalid state error, 0, 0
>
> Safari: invalid state error, 0, 0, 0
>
> Firefox: 0, 0, 0, 0, 0
>
> 5. In http, you can do if (this.readyState === 4 && this.status === 200). 
> However, for file://, you have to do (this.readyState === 4 && (this.status 
> === 200 || document.location.protocol === "file:") or assume this.status of 0 
> means "file:".
>
> It'd be cool if browsers would match each other (including IE supporting xhr 
> for file://) and either throw an exception for file not found like Firefox 
> does or simulate http statuses for local files (200 and 404 for example), or 
> some combo so a page will work locally and on the server without change.

What do you think about the following?

The xhr spec could make a general recommendation for non-http
requests. It wouldn't have to mention "file:" specifically.

It could recommend something like this:

1. .readyState always makes it to 4.
2. .open() doesn't throw for "file not found" or "access denied".

3. When .readyState is 4, .status is:

404 for "file not found"
200 for "file is found and readable"
403 for "forbidden"
401 for "authorization required"
400 for "bad request" (like trying to open "c:\\file.xml" instead of
"file:///c:/file.xml" or "file://localhost/c:/file.xml")

etc.

4. .responseText would be available for 200 and .responseXML would be
if the content was successfully parsed as XML or null otherwise.

Then, you could handle specif errors like this:

var req = new XMLHttpRequest();
req.open("GET",
"file:///c:/Documents%20and%20Settings%20/user/Desktop/data.xml");
req.onreadystatechange = function() {
if (this.readyState === 4) {
if (this.status === 200) {
alert(this.responseXML);
alert(this.responseText);
} else if (this.status === 404) {
alert('file not found');
} else if (this.status === 403) {
alert('forbidden');
} else if (this.status === 401) {
alert('authorization required');
} else if (this.status === 400) {
alert("bad request");
}
}
}
req.send();

(alerts are just an example)

-- 
Michael

Re: Input events, checkboxes and radio buttons

[Michael A. Puls II]

On Sat, 20 Jun 2009 06:35:16 -0400, Anne van Kesteren   
wrote:


On Fri, 19 Jun 2009 19:57:20 +0200, Erik Arvidsson  
 wrote:
The HTML5 spec says to fire the input event when the user changes a  
radio

button or a checkbox. However, the spec says "When the input event
applies, any time the user causes the element's *value* to change". For
input[type="radio"] and input[type="checkbox"] the input event should be
fired any time the user causes the element's *checked* property to
change.


The input event does not apply to radio/checkbox. (This is stated in the  
radio/checkbox sectons.)


Are you sure?

The table under  
  
(scroll down a bit) shows "yes" for the input event under the  
radio/checkbox column.


--
Michael

Re: [XHR] XMLHttpRequest name

[Michael A. Puls II]

On Tue, 23 Jun 2009 08:46:35 -0400, Glen  wrote:


Hi,

Why are XML and Http capitalized differently? Shouldn't it be
XmlHttpRequest?


I don't know. I have a habit of typing XMLHTTPRequest.

--
Michael

Re: New FileAPI Draft | was Re: FileAPI feedback

[Michael A. Puls II]

On Mon, 17 Aug 2009 20:12:50 -0400, Arun Ranganathan   
wrote:



Nikunj R. Mehta wrote:
 On Aug 12, 2009, at 7:29 AM, Arun Ranganathan wrote:
 Gregg Tavares wrote:
How about this?
 Why make a new API for getting the contents of a file (local or  
otherwise)

when we already have one which is XHR?
 What if FileList was just array of File objects where each File object  
is

just a URL in the format
 "filedata: uuid, filename"
 Then you can use that URL anywhere in HTML a URL is valid. script, img,
audio, video, css, AND XHR
 That would mean you wouldn't be adding a new API to get the contents of  
a
file. If you want the contents just use XHR and use the URL from the  
File in

the FileList.
 You could add a few more functions to XHR like request.getAsDataURL(),
request.getAsTextInEncodiing(), etc. if need be if they are neede
 Today, it's possible to use XHR from "privileged web content" in  
Firefox to access file:// URLs; the drawback is that these don't return  
HTTP responses, and of course there are security considerations.
 As stated, the XHR algorithm for open() [1] allows relative references  
and resolves them relative to the document base URI. Does that mean that  
if the document was loaded using file: uri, then the XHR could be used  
for loading a file?
Currently, this behavior is not standard, and there are interoperability  
issues across user agents.  Michael Puls II did ran some tests some time  
ago and posted these on this listserv:

 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0200.html


I have a more specific proposal about simulating HTTP status codes for  
file: operations that I'll be posting soon.


I also have an alternate proposal to post soon for a simple FileReader api  
to replace the local file loading part of DOM3 L&S, document.load and XHR.


I also have some questions about using the new FileAPI to load files on  
file:// without the use of .


(Will post these things in new threads soon.)

--
Michael

FileReader objects for loading local files on local web pages

[Michael A. Puls II]

I think it'd be great to have a *simple to use* API specifically for  
loading local files on local pages (file://).


There's already DOM3 Load and Save, but few want anything to do with that  
(it's not simple for one).


There's also the previous document.load, but it's half broken in Opera,  
not implemented in Safari (unless things have changed recently) and isn't  
very good with error handling in Firefox. In other words, it's a mess.


There's also XHR, but it doesn't really support file://. Firefox, Safari  
and Opera have implemented file:// access, but they don't all use the same  
security restrictions, don't all handle errors the same and don't simulate  
HTTP status codes for local file operations. This makes loading a local  
file a mess with XHR and makes it so you have to use different conditions  
in the readystatechange callback compared to HTTP. It's possible though to  
load a local file, but it's impossible to differentiate between the  
different type of errors (like file not found, access denied, read error,  
cross-origin attempt etc.). IE doesn't support accessing file:// with XHR,  
so can't comment on it.


With that said, here's an idea (and what I'd like):

There should be a FileReader interface that supports just load(fileURI)  
and error and load events (via onerror/onload or through addEventListener).


Then, there'd be different types of reader objects that inherit from  
FileReader. The two that I'm suggesting are TextFileReader and  
BinaryFileReader. (I believe it's better to separate functionality into 2  
separate objects instead of mixing things.)


They would work like this:

var treader = new TextFileReader();
treader.addEventListener("load", function(e) {
alert(e.text);
}, false);
treader.addEventListener("error", function(e) {
alert(e.error.code);
}, false);

and

var breader = new BinaryFileReader();
breader.addEventListener("load", function(e) {
alert(e.bytes);
}, false);
breader.addEventListener("error", function(e) {
alert(e.error.code);
}, false);

'load' does not fire if there's an error. 'error' fires for the first  
error (the code would return after the first error).


Nothing throws an exception. The author can do that in the error handler  
if desired. That way, you can do things how you want. You can also easily  
wrap things to use callback functions instead if you really wanted.


For the load event objects, there'd be a BinaryReaderLoadEvent that has a  
bytes getter and a TextReaderLoadEvent that has a text getter. They would  
inherit from Event. (I like these separate instead of having one event  
object that has both .text and .bytes where one might be null or something)


For the error event object, there'd be a FileReaderErrorEvent object that  
has an error getter that returns a FileReaderException object, which  
inherits from DOMException and has a code getter that returns different  
error codes for file not found etc. (that would have to be agreed upon).


It'd all look something like this (don't know idl stuff very well, but it  
should be good enough to get the idea across)


interface FileReader {
onload
onerror
addEventListener
void load(uri);
};

interface TestFileReader : FileReader {

};

interface BinaryFileReader : FileReader {

};

interface TextFileReaderLoadEvent : Event {
readonly attribute string text;
};

interface BinaryFileReaderLoadEvent : Event {
readonly attribute array bytes;
};

interface FileReaderException : DOMException {
readyonly attribute unsigned short code;
};
// const unsigned short NOT_FOUND_ERR = 1;
// const unsigned short ACCESS_DENIED_ERR = 2;
// const unsigned short ORIGIN_VIOLATION_ERR = 3;
// const unsigned short READ_ERROR_ERR = 4;

interface FileReaderErrorEvent : Event {
readonly attribute FileReaderException error;
};

All the objects should be exposed on the window object so one can  
extend/override them with prototypes and getters etc. if desired.


There'd by no sync version, only async like the examples above.

I don't think progress events and reading the file in chunks are needed  
for this simple API.


I also specifically left out xml parsing, as that can be done with  
DOMParser once you get the file text. (If DOMParser has shortcomings, it  
should be improved.)


As for the encoding used for TextFileReader when reading the file, not  
sure. I expect it to work just like document.load, XHR (with file://) and  
DOM3 Load & Save work.


If you try to use a FileReader on a protocol besides file://, you'd get  
the ORIGIN_VIOLATION_ERR in the error listener. (Note that  
file://bark/dir/test.html <- and file://meow/dir/file.txt would be a  
cross-origin violation for example.)


You'd also get the ORIGIN_VIOLATION_ERR in the error listener if you try  
to use a FileReader on a non-file:// page.


Error handling is very important. -- Not for debugging, but for the  
user-informative 'why things went wrong'. I absolutely hate it when a  
generic

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

[Michael A. Puls II]

Currently, xhr's this.status model doesn't work too well with file://.

One big reason for this is that browser implementations don't simulate  
HTTP status codes for file:// operations. In short, this.status always  
equals 0, which means you have to do something like this:


var req = new XMLHttpRequest();
req.onreadystatechange = function() {
if (this.readyState === 4) {
if (this.status === 200 || document.location.protocol === "file:")  
{


}
}
};
req.open("GET", "local_file.txt");
req.send();

You could also try (this.status === 200 || this.status === 0) if you  
assume that the status will only be 0 for "file:" and no other condition.


Even then, depending on the browser implementation, if the local file is  
not found, you might get an exception thrown in one browser or no  
exception thrown and just this.responseText set to "" in another.


Further, for file://, you can't tell the difference between a file not  
found error and a cross-origin attempt error (or an empty file in some  
cases). You also can't specifically tell if the error is because access to  
the file is denied.


Although XHR wasn't designed for file:// and its behavior remains  
undefined in the spec, I believe simulating HTTP status codes for file  
operations could help big time with these problems.


I'm not saying file: support should be added to the XHR spec, but there  
should be some 'file:// for XHR' guidelines that browsers could use.


file:// should really be a first class citizen, imo.

Example:

var req = new XMLHttpRequest();
req.onreadstatechange = function() {
switch (this.readyState) {
case 0: // Unsent state
break;
case 1: // Open state
break;
case 2: // Headers_Received state
break;
case 3: // Loading state
break;
case 4: // Done state
switch(this.status) {
case 200: // OK
break;
case 404: // Not Found
break;
case 401: // Authorization required
break;
case 403: // Forbidden
break;
case 405: // Method not allowed
break;
case 501: // Not implemented
break;
case 414: // Request URI too long
break;
case 415: // Unsupported mime type
break;
case 0: // Done state error flag is true for some reason
break;
default: // Unsupported status codes
}
break;
default: // Unsupported states
}
};
try {
req.open("GET", "local_file.txt");
req.send();
} catch(error) {
alert(error);
}

1. For file:// access, make sure this.readyState always reaches 4.

2. For file:// access, simulate the appropriate HTTP status code for the  
result so that this.status and this.statusText can be used properly.


3. Don't have open() throw for "file not found" and use 404 for  
this.status instead.


4. If file:// access isn't implemented (like in IE), don't have open()  
throw. Instead, make this.status be 501.


5. If the request URI result in too long of a path, use status code 414.

6. If the request URI points to a certain type of file the *browser*  
doesn't want to allow access to (maybe an .exe), use status code 415.


7. If a method besides "GET" is used for open(), don't throw and use  
status code 405.


8. Don't have open() throw for cross-domain security restriction. Instead,  
use status code 403.


9. If the user doesn't have access to the file, don't have open() throw  
and instead use status code 401.


10. responseText and responseXML should be null unless the status is 200.

11. For any other errors on .open(), SYNTAX_ERR or SECURITY_ERR should be  
throw.


Easier Alternative:

1. Make sure this.readyState always makes it to 4.

2. Make open() throw for everything. The only time it would not throw is  
if the file is found and accessible.


3. Make this.status equal 200.

4. For #1, throw different types of errors for each case. File not found,  
access denied, cross-origin attempt etc.


Ulimately though, what I think would be great is if you could use XHR on  
HTTP or locally (on file://) while using the exact same code to load a  
file.


For example, the following should work exactly the same on both file and  
http.


var req = new XMLHttpRequest();
req.onreadystatechange = function() {
if (this.readyState === 4) {
if (this.status === 200) {
alert(this.responseText);
} else if (this.status === 404) {
alert("file not found");
}
}
};
req.open("GET", "file_in_same_dir.txt");
req.send();

Also, some have suggested that DOM3 Load & Save and document.load are not  
needed if you have XHR (and DOMParser for the XML part). However, current  
browser implementions of XHR

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 06:22:49 -0400, timeless  wrote:


I'd rather we formally indicate that using file urls in
XMLHttpRequests is not expected to work with an explanation that there
are security concerns which prevent XMLHttpRequest safely exposing
arbitrary file urls.


Saying in the spec that it's not expected to work sounds fine.

However, 3 out of the 4 main browsers support it. Behavior and security  
could be aligned and improved.


For example:

1. Don't allow access to file: files from a non-file: origin.

2. "file://localhost/" and "file:///" are equivalent. (Browsers convert to  
the one they support.)


3. file://bark/path and file://meow/path are different origins.

4. Accessing a non-file: origin resource from a file: origin can be  
allowed (like it is in Safari), at least as a non-default option.


5. Make file:///c:/ and file:///d:/ different origins if necessary, so  
access isn't allowed across drive boundaries. More specifically, only  
allow file:///c:/dir/test.html to access files in file:///c:/dir/ and  
sub-directories of file:///c:/dir/. I think Firefox does something like  
this.


I'm not making light of security, but I believe it can be done.  Any  
additional rules that are agreed upon should improve file:// security in  
browsers, not make it worse.



People who need access to local files should use a locally bound web
server or if the content is something they control, JSON or an iframe.


I disagree with the 'should'. They can, and they'd *currently* be better  
off. But, I don't think it has to be that way.



something like:
In order for implementations to protect their users, XMLHttpRequest
implementations MAY choose not to support file urls or MAY choose
whatever error values they like.


That sounds good.

Say that file: security wasn't an issue and compat with xhr was desired.  
Do you consider the status code idea a good way to make file: work better  
with xhr, or does simulating status codes sound too complicated?


Thanks

--
Michael

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 05:50:13 -0400, Anne van Kesteren   
wrote:


On Tue, 18 Aug 2009 09:19:03 +0200, Michael A. Puls II  
 wrote:

I'm not saying file: support should be added to the XHR spec, but there
should be some 'file:// for XHR' guidelines that browsers could use.


Nowhere in the documentation of the Web platform there is documentation  
for things to do with file URLs. In fact, file URLs are woefully  
underdefined.


It doesn't have to stay that way though.

I do not think adding text to the XMLHttpRequest specification is a good  
use of our time until we actually decide that interoperability on the  
file URL level matters


I personally think it matters. But, would like to know if anyone else  
cares.



and we have someone to drive that effort.


Well, cross-origin issues in browsers should be pretty  
protocol-independent. That should mostly leave file: URI format (described  
better than RFC 1738), access limits (what directories from the base are  
allowed), and HTTP status code equivalents (for use with things like XHR).


Are vendors interested in having all of that as an RFC or W3C spec for  
example?


Thanks

--
Michael

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 14:38:07 -0400, Arun Ranganathan   
wrote:



Michael,

I'd like to distinguish between file:// and filedata: which is what the  
current FileAPI proposes. While file:// behavior is undefined and pretty  
vague across user agents, filedata: is spec'd to be used within web  
applications, has a lifetime, an origin policy, and does return a subset  
of HTTP status codes (which are not 405 if requested with GET).  I'd say  
that file:// is convenient for user agents to surface local files for  
users, but filedata: could be used within web applications.  In  
particular:




2. For file:// access, simulate the appropriate HTTP status code for  
the result so that this.status and this.statusText can be used properly.


3. Don't have open() throw for "file not found" and use 404 for  
this.status instead.


4. If file:// access isn't implemented (like in IE), don't have open()  
throw. Instead, make this.status be 501.


5. If the request URI result in too long of a path, use status code 414.

6. If the request URI points to a certain type of file the *browser*  
doesn't want to allow access to (maybe an .exe), use status code 415.


7. If a method besides "GET" is used for open(), don't throw and use  
status code 405.


These behaviors match what filedata: might do (but not exactly as you  
say so above).

http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html#filedataurl-if

There are a few conditions that are not properly specified currently in  
the editor's draft, but I'd like to remedy that soon :-)


I think that the use cases you have for file:// being a first class  
citizen of web (in terms of use across all request mechanisms) could be  
applied to filedata: instead.


Thanks.

Using filedata: and the FileAPI instead of file: with xhr, seems like it'd  
work. However, how do you get a fileData object without type="file">?


Would you have to shoehorn it like the following?

function getLocalFileData(fileURI) {
var input = document.createElement("input");
input.type = "file"
input.value = fileURI; // (relative or absolute) to local file
return input.fileList.files[0];
}

--
Michael

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 14:59:28 -0400, Arun Ranganathan   
wrote:



Michael A. Puls II wrote:


Using filedata: and the FileAPI instead of file: with xhr, seems like  
it'd work. However, how do you get a fileData object without type="file">?


Whereas file:// gives you (sometimes constrained) access to the file  
system, including directories, etc., filedata: is tightly coupled to a  
single file, which the user has chosen.  Thus, you can't decouple the  
file selection process (which generates UI, via input type="file) from a  
given selected file's filedata: URL.  Early versions of the draft had a  
FileDialog interface, but this was controversial, and is not an active  
part of this draft.


O.K. Thanks. fileadata: wouldn't work then if the user has to choose the  
file.


--
Michael

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 15:09:53 -0400, Jonas Sicking  wrote:


On Tue, Aug 18, 2009 at 12:03 PM, Michael A. Puls
II 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.



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.


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.


I don't believe a local server should be needed in this case when there's  
already a file system to work with.


I wasn't worried about any of this as I thought Firefox, Safari and IE  
were going to eventually support DOM3 L&S and that Opera was going to  
improve their implementation. But, the feedback I've seen on this list and  
the Mozilla bug reports seems to say otherwise. So, I'm hoping for an  
alternative to DOM3L&S that's simpler so vendors will implement it.


Hope that helps and thanks.

--
Michael

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 15:25:35 -0400, Adam Barth  wrote:


On Tue, Aug 18, 2009 at 10:30 AM, Michael A. Puls
II wrote:

However, 3 out of the 4 main browsers support it. Behavior and security
could be aligned and improved.


We should tread carefully here.  The security model for file URLs
isn't fully developed yet.


Yes, of course.


For example:

1. Don't allow access to file: files from a non-file: origin.

2. "file://localhost/" and "file:///" are equivalent. (Browsers convert  
to

the one they support.)

3. file://bark/path and file://meow/path are different origins.


It's unclear whether supporting these kinds of URLs is worth the
security issues.  Keep in mind that getting this to work properly
involves the cooperation of plug-in vendors.


By 'supporting', you mean in XHR, right? They're already supported in  
browsers for everything else.


I believe it's better to expose file: than platform paths that are  
different with each platform.


4. Accessing a non-file: origin resource from a file: origin can be  
allowed

(like it is in Safari), at least as a non-default option.


This is a poor security choice.  The major browsers have been slowly
moving away from the model where file URLs can access web URLs.  I
suspect Safari may remove this ability in the future.


Yes, it's probably better left as a non-default, advanced user option.


5. Make file:///c:/ and file:///d:/ different origins if necessary, so
access isn't allowed across drive boundaries. More specifically, only  
allow

file:///c:/dir/test.html to access files in file:///c:/dir/ and
sub-directories of file:///c:/dir/. I think Firefox does something like
this.


Firefox has the most innovative security model for file URLs.  What
they do is much more subtle than what you describe above.  Hopefully
their model will spread to other implementations.  However, this
doesn't seem like the right forum to push that agenda at this time.


Where do you suggest then?


I'm not making light of security, but I believe it can be done.  Any
additional rules that are agreed upon should improve file:// security in
browsers, not make it worse.


Your suggestions are a mix of security improvements and
disimprovements.


What part is the disimprovement? The Safari case?

Note: I posted this suggestion to see if anyone thought it was a good  
idea. If not, I'll try to come up with something better. Or, are you  
saying that no matter what I come up with, if it deals with file:, it's a  
no-go?


Thanks

--
Michael

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 16:27:29 -0400, Adam Barth  wrote:


On Tue, Aug 18, 2009 at 12:50 PM, Michael A. Puls
II wrote:
On Tue, 18 Aug 2009 15:25:35 -0400, Adam Barth   
wrote:

On Tue, Aug 18, 2009 at 10:30 AM, Michael A. Puls
II wrote:

3. file://bark/path and file://meow/path are different origins.


It's unclear whether supporting these kinds of URLs is worth the
security issues.  Keep in mind that getting this to work properly
involves the cooperation of plug-in vendors.


By 'supporting', you mean in XHR, right? They're already supported in
browsers for everything else.


I'm not sure browser behavior here is as interoperable as you seem to
believe.  For example, I don't think many browsers divide these kinds
of file URLs into separate origins.


Firefox has the most innovative security model for file URLs.  What
they do is much more subtle than what you describe above.  Hopefully
their model will spread to other implementations.  However, this
doesn't seem like the right forum to push that agenda at this time.


Where do you suggest then?


This sounds like a good topic for HTML 6.


O.K.


I'm not making light of security, but I believe it can be done.  Any
additional rules that are agreed upon should improve file:// security  
in

browsers, not make it worse.


Your suggestions are a mix of security improvements and
disimprovements.


What part is the disimprovement? The Safari case?


I'm not sure what you mean by the "Safari case,"


Requesting an http: resource from a file: page.


but it's unclear
whether dividing file URLs by UNC host name makes sense.


It's what 3.10 of RFC 1738 recommends. RFC 2396 ditched specifying stuff  
about specific schemes, which means file: needs to be specified in a  
different doc. RFC 1738 is all there is right now afaik.



For example,
that wouldn't appear to work well in a deployment that uses AFS.


I'm not sure how things work for AFS. What do paths look like?


Also, allowing access to web URLs from file URL is probably a
disimprovement as well.


O.K.

Note: I posted this suggestion to see if anyone thought it was a good  
idea.
If not, I'll try to come up with something better. Or, are you saying  
that

no matter what I come up with, if it deals with file:, it's a no-go?


I'm saying this is a complex topic that will likely take many years of
experimentation to get right.  Writing this into the XHR spec now is
probably not the most expedient way to move this topic forward.


O.K.

Here's a list of topics we should tackle before the file URL security  
for XHR:


1) Parsing of file URLs.  Currently browsers parse these URLs with
very different algorithms.


True. Also, the main issue I've seen is that plug-ins often don't treat  
"file:///c:/" and "file://localhost/c:/" as the same.



2) Cross-frame access from a file URL to a web URL.


They're different origins. For example, document.domain for  
file://localhost/c:/ is "localhost" (in Opera).



3) Cross-frame access from one file URL to another.


Depends if the origins of the file URIs are the same or not.  
file://localhost/ | file:/// (files on your computer), file://bark/ and  
file://meow/ (files on intranet shares etc.).



4) Sub-resource loading from file URLs.


Sub-resource?

The short answer is to follow the same security restrictions as you would  
with HTTP.


You can't access file: from http.
You can't do cross-origin http (without the access-control stuff)
You can't communicate between windows/frames of different http domains.

There is postMessage though. Wonder if that works from file.


We need to consider the big picture here instead of focusing narrowly
on XHR, which is why I recommend tackling this issue as part of HTML


Yes, agreed. Thanks

--
Michael

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 17:33:24 -0400, Nikunj R. Mehta  
 wrote:




On Aug 18, 2009, at 12:19 AM, Michael A. Puls II wrote:

4. If file:// access isn't implemented (like in IE), don't have open()  
throw. Instead, make this.status be 501.


This is a breaking change to the XHR spec which asks to throw an error.  
Have you considered the effect of making the proposed change?


Yes.

"8. Don't have open() throw for cross-domain security restriction. Instead,
use status code 403."

does the same.

I could live without those changes as long as there was information for  
the security_err exception so that you could tell the difference between  
the 2.


Of course, the "Easier Alternative:" I mentioned in  
<http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0686.html>  
might be a better way to do things.


--
Michael

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 17:50:02 -0400, Adam Barth  wrote:

On Tue, Aug 18, 2009 at 2:40 PM, Michael A. Puls  
II wrote:
On Tue, 18 Aug 2009 16:27:29 -0400, Adam Barth   
wrote:

For example,
that wouldn't appear to work well in a deployment that uses AFS.


I'm not sure how things work for AFS. What do paths look like?


/afs/cs.stanford.edu/u/abarth

In your notation, that would be

file://localhost/afs/cs.stanford.edu/u/abarth


So, if you access the abarth directory in your browser's address field,  
it'll say:


file:///afs/cs.stanford.edu/u/abarth (or  
file://localhost/afs/cs.stanford.edu/u/abarth in Opera)

?

If so, then indeed the access has to be further restricted by the  
directory also.


Or, does it say something else?


Also, allowing access to web URLs from file URL is probably a
disimprovement as well.


O.K.


I get to issue transactions on your bank account!  Good times (well,
for me at least).


:)

Thanks

--
Michael

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 18:10:41 -0400, Adam Barth  wrote:

On Tue, Aug 18, 2009 at 2:59 PM, Michael A. Puls  
II wrote:

So, if you access the abarth directory in your browser's address field,
it'll say:

file:///afs/cs.stanford.edu/u/abarth (or
file://localhost/afs/cs.stanford.edu/u/abarth in Opera)
?


Yep.


O.K. Thanks.

If so, then indeed the access has to be further restricted by the  
directory

also.

Or, does it say something else?


The point I'm trying to make is that the security model for file URLs
is tricky.


Point definitely taken.


Mozilla does indeed separate by directory in an
interesting way.


Is the exact way documented that you know of?


 When interacting with the file system, we should be
careful to consider non-Windows file systems as well.


Point taken.

We haven't even gotten into the fun of the /dev or /proc directories  
yet.  :)


If you have access to dev and try to load a path to a current device, what  
happens in browsers currently?


--
Michael

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 20:14:00 -0400, Adam Barth  wrote:

On Tue, Aug 18, 2009 at 3:38 PM, Michael A. Puls  
II wrote:
On Tue, 18 Aug 2009 18:10:41 -0400, Adam Barth   
wrote:

Mozilla does indeed separate by directory in an
interesting way.


Is the exact way documented that you know of?


There's is some description on the Mozilla developers wiki, but the
implementation didn't match that description last time I investigated
this topic.


Thanks. Here's what I see:

Page: file:///c:/documents%20and%20settings/user/desktop/test.html

File to fetch with "GET" and XHR - result

Opera
file:///d:/test.txt - allowed
file:///c:/test.txt - allowed
file:///c:/documents%20and%20settings/user/test.txt - allowed
test.txt - allowed
dir/test.txt - allowed
../test.txt - allowed
http://www.google.com/webhp - Security violation exception
file_that_does_not_exist.txt - No exception thrown, but responseText is  
empty


Safari
file:///d:/test.txt - allowed
file:///c:/test.txt - allowed
file:///c:/documents%20and%20settings/user/test.txt - allowed
test.txt - allowed
dir/test.txt - allowed
../test.txt - allowed
http://www.google.com/webhp - allowed
file_that_does_not_exist.txt - No exception thrown, but responseText is  
empty


Firefox:
file:///d:/test.txt - "Access to restricted URI denied" exception
file:///c:/test.txt - "Access to restricted URI denied" exception
file:///c:/documents%20and%20settings/user/test.txt - "Access to  
restricted URI denied" exception

test.txt - allowed
dir/test.txt - allowed
../test.txt - "Access to restricted URI denied" exception
http://www.google.com/webhp - No exception thrown, but responseText is  
empty

file_that_does_not_exist.txt - "Access to restricted URI denied" exception

Things that could be improved:

1. For Firefox and file_that_does_not_exist.txt, "Access to restricted URI  
denied" isn't the best message. Something like "file not found" would be  
way better.


2. For Firefox, http://www.google.com/webhp should throw an exception  
instead of just making responseText "".


3. For Safari, http://www.google.com/webhp should throw an exception.

4. For Opera and Safari, file_that_does_not_exist.txt, should throw an  
exception instead of responseTxt just being "".


5. For Opera and Safari, file:///d:/test.txt, file:///c:/test.txt,  
file:///c:/documents%20and%20settings/user/test.txt and ../test.txt should  
all throw an exception like Firefox does.


Firefox only allowing access to files in  
"file:///c:/documents%20and%20settings/user/desktop/" and its  
subdirectories seems great.


If you have access to dev and try to load a path to a current device,  
what

happens in browsers currently?


I recommend the experimental method.  :)


Gotcha.

--
Michael

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 21:13:20 -0400, Jonas Sicking  wrote:


Without commenting on the results in other browsers:

On Tue, Aug 18, 2009 at 5:21 PM, Michael A. Puls  
II wrote:

Things that could be improved:

1. For Firefox and file_that_does_not_exist.txt, "Access to restricted  
URI
denied" isn't the best message. Something like "file not found" would  
be way

better.


Agreed.


2. For Firefox, http://www.google.com/webhp should throw an exception
instead of just making responseText "".


Note that we let you load data from this url according to the CORS
spec [1]. So we can't just throw. But you should get an error event
eventually, do you not?


With XHR2 and an error listener, 'error' does fire, but the event object  
is just a progress event with no data about the error.


--
Michael

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 21:08:25 -0400, Jonas Sicking  wrote:


On Tue, Aug 18, 2009 at 12:39 PM, Michael A. Puls
II wrote:
On Tue, 18 Aug 2009 15:09:53 -0400, Jonas Sicking   
wrote:



On Tue, Aug 18, 2009 at 12:03 PM, Michael A. Puls
II 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

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

[Michael A. Puls II]

On Tue, 18 Aug 2009 22:34:47 -0400, Jonas Sicking  wrote:

On Tue, Aug 18, 2009 at 7:13 PM, Michael A. Puls  
II 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  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

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

[Michael A. Puls II]

On Wed, 19 Aug 2009 14:25:09 -0400, Jonas Sicking  wrote:

On Tue, Aug 18, 2009 at 8:48 PM, Michael A. Puls  
II wrote:

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


Indeed, I'm sure there are bugs aplenty here. But that's more due to
buggy implementations than shortcomings in the specs. Best way to get
movement there is to file bugs with testcases (well, even better would
be to attach patches as well :) ).


Understdood.


However note that I'm not sure that failing to parse should fire an
error event. For someone only caring about responseText things loaded
just fine. (I think I actually changed firefox from what you describe
to what I describe sometime after Firefox 2, for this very reason).
The "XML" part of the name "XMLHttpRequest" was never very true.


Ah, understood. I think I could work around that by checking responseXML  
to see if it's right. If it's not, perhaps I could manually dispatch an  
'error', if there's a way to manually, create and init a progress event so  
that you can dispatch it. Will play with that.


Thanks

--
Michael

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

[Michael A. Puls II]

On Wed, 19 Aug 2009 15:18:03 -0400, Michael A. Puls II  
 wrote:



However note that I'm not sure that failing to parse should fire an
error event. For someone only caring about responseText things loaded
just fine. (I think I actually changed firefox from what you describe
to what I describe sometime after Firefox 2, for this very reason).
The "XML" part of the name "XMLHttpRequest" was never very true.
 Ah, understood. I think I could work around that by checking  
responseXML to see if it's right. If it's not, perhaps I could manually  
dispatch an 'error', if there's a way to manually, create and init a  
progress event so that you can dispatch it. Will play with that.


I can do this in FF:

function loadXMLFile(fileURI, load_callback, error_callback) {
var req = new XMLHttpRequest();
req.addEventListener("load", function(e) {
var doc = e.target.responseXML;
if (doc instanceof XMLDocument && doc.documentElement instanceof  
Element &&  
doc.getElementsByTagNameNS("http://www.mozilla.org/newlayout/xml/parsererror.xml";,  
"parsererror").length === 0) {

load_callback(e);
} else {
var evt = document.createEvent("ProgressEvent");
evt.initProgressEvent("error", false, false,  
e.lengthComputable, e.loaded, e.total);

evt.message = "XML Parse Errror";
req.dispatchEvent(evt);
}
}, false);
req.addEventListener("error", function(e) {
if (typeof e.message !== "string") {
e.message = "Unknown error - Perhaps cross-origin violation";
}
error_callback(e);
}, false);
try {
req.open("GET", fileURI);
req.send();
} catch (err) {
var evt = document.createEvent("ProgressEvent");
evt.initProgressEvent("error", false, false, 0, 0, 0);
evt.message = "Some kind of Access error - Could be File Not  
Found, Access Denied or something else";

req.dispatchEvent(evt);
}
}

// Usage:
loadXMLFile("test.xml", function(e) {
alert(e.target.responseXML);
}, function(e) {
alert(e.message);
});

Then, XHR2 would be wrapped again for a loadTextFile().

Anyway, that at least makes the load and error callbacks fire only/exactly  
when they should and still passes in a ProgressEvent, but with a .message  
getter with some error info. Still not possible to get the error info  
specific enough for each case though.


With _lookupGetter__ and __defineGetter__, I might be able to make .status  
return 200, 404 and 403 for some of the conditions if I wanted.


In the try{} part, I could create an anchor element, set its href to  
fileURI so that it's resolved and compare it to the document's location to  
make sure the requested file is in the document's directory or one of its  
subdirectories. That way, I could at least detect that particular security  
violation and fire 'error' for it.


But, all of this is just trying to force what XHR and ProgressEvents were  
not even closely designed to do. Wrapped like that, it is at least a  
little bit closer to DOM3 L&S.


--
Michael

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

[Michael A. Puls II]

On Wed, 19 Aug 2009 23:50:18 -0400, Michael A. Puls II  
 wrote:


On Wed, 19 Aug 2009 15:18:03 -0400, Michael A. Puls II  
 wrote:



However note that I'm not sure that failing to parse should fire an
error event. For someone only caring about responseText things loaded
just fine. (I think I actually changed firefox from what you describe
to what I describe sometime after Firefox 2, for this very reason).
The "XML" part of the name "XMLHttpRequest" was never very true.
 Ah, understood. I think I could work around that by checking  
responseXML to see if it's right. If it's not, perhaps I could manually  
dispatch an 'error', if there's a way to manually, create and init a  
progress event so that you can dispatch it. Will play with that.


I can do this in FF:

[...]

A little better error handling:
<http://shadow2531.com/opera/testcases/xhr/file_reader.js>

I drop my request for HTTP status code compat.

I'll try to get the exception info vagueness fixed in browsers to improve  
wrapability of XHR instead.


--
Michael

Re: FileReader objects for loading local files on local web pages

[Michael A. Puls II]

On Mon, 24 Aug 2009 06:13:22 -0400, Robin Berjon  wrote:


Hi,

On Aug 18, 2009, at 04:37 , Michael A. Puls II wrote:
I think it'd be great to have a *simple to use* API specifically for  
loading local files on local pages (file://).


The DAP WG is just getting started and will amongst other things define  
an API for file system access. Whether it will be available to local  
pages is a matter that I believe is likely to be solved in a manner  
different from the one you are proposing but mechanisms to make that  
possible are certainly part of the deal. I encourage you to join the  
public list (where all business is conducted) as well as to review the  
existing proposals.


Thanks.
Is <http://www.w3.org/2009/dap/> the right page for info etc.?

--
Michael

Re: [EventSource] feedback from implementors

[Michael A. Puls II]

On Fri, 18 Sep 2009 11:37:24 -0400, Per-Erik Brodin  
 wrote:



When parsing an event stream, allowing carriage return, carriage return
line feed, and line feed to denote line endings introduces unnecessary
ambiguity into the spec. For example, the sequence "\r\r\n\n" could be
interpreted as three or four line endings.


That would always be 3 lines: a mac, a windows and a nix. "\n\r\n\r" would  
be the reverse order, but still 3.


Universal newline normalization for input with mixed newline formats:

// normalize newlines to \n
.replace(/\r\n|\r/g, "\n");

// normalize newlines to \r\n
.replace(/\r\n|r|\n/g, "\r\n");

// normalize newlines to \r
.replace(/\r\n|\n/g, "\r");

Ideally, I think it's often best to do the first to normalize to \n for  
processing (like if you need to know line count) and then normalize to a  
different format *if needed* afterwards.


IMO

--
Michael

Re: [EventSource] feedback from implementors

[Michael A. Puls II]

On Mon, 21 Sep 2009 11:39:14 -0400, Per-Erik Brodin  
 wrote:



Michael A. Puls II wrote:

On Fri, 18 Sep 2009 11:37:24 -0400, Per-Erik Brodin wrote:


When parsing an event stream, allowing carriage return, carriage return
line feed, and line feed to denote line endings introduces unnecessary
ambiguity into the spec. For example, the sequence "\r\r\n\n" could be
interpreted as three or four line endings.
 That would always be 3 lines: a mac, a windows and a nix. "\n\r\n\r"  
would be the reverse order, but still 3.

So what you are saying is that "\r\n" will always be a Windows line
ending and never a Mac line ending followed by a Unix line ending?


Ideally, yes, imo.


 Universal newline normalization for input with mixed newline formats:
 // normalize newlines to \n
.replace(/\r\n|\r/g, "\n");
 // normalize newlines to \r\n
.replace(/\r\n|r|\n/g, "\r\n");
 // normalize newlines to \r
.replace(/\r\n|\n/g, "\r");

While regular expressions are greedy by default, I have been told that
there is no way to express such behavior using ABNF. For what it is
worth, that means that the current ABNF definition of the event stream
format can't stand on its own.

 Ideally, I think it's often best to do the first to normalize to \n  
for processing (like if you need to know line count) and then normalize  
to a different format *if needed* afterwards.

 IMO


Keep in mind that we are parsing a continuous stream where data arrives
in chunks. It is entirely possible for a "\r\n" pair to be split up
between two chunks which could be handled by either 1) dispatching an
event immediately when receiving a carriage return and then upon
reception of the next chunk "remember" that the last character in the
previous chunk was a carriage return and discard the first character if
it happens to be line feed, or 2) not dispatching an event until the
next character after carriage return has been received which could lead
to delays in event dispatch. Both these options are far from ideal.


#1 sounds like it makes great sense, imo. Ideally, even if you're handling  
things in chunks, the end result should be the same as if you got it all  
at once. In other words, if you can help it, don't let the chunkiness mess  
up your desired newline handling :).


Of course, it'd be nice if there's only ever \n to deal with.

--
Michael

Re: [DOMCore] Attr

[Michael A. Puls II]

On Fri, 10 Sep 2010 19:05:56 -0400, Maciej Stachowiak   
wrote:




On Sep 10, 2010, at 5:35 AM, Anne van Kesteren wrote:


Hi,

I thought I'd email some people directly to figure out what we can do  
with Attr as it is one of the last bits not defined yet in Web DOM Core  
and I would sort of like to handle it so the specification is  
"complete" (at least beyond the initial 80%).


Attr nodes have traditionally allowed child nodes to account for  
EntityReference nodes, a concept which no browser vendor implemented.  
While it is great nobody implemented the complexity that is  
EntityReference, it has left us with a fair bit complexity for Attr  
nodes, which is implemented.


There are several ways we can simplify Attr nodes (some are orthogonal):

1) We can drop the concept of Attr nodes having children. In Gecko it  
already depends on how you created the Attr node [1][2] whether it can  
have children or not. I think we should either consistently allow  
children or not at all (preferred).


2) We can drop the concept of Attr being a Node. This would drastically  
reduce the footprint of the object. The difficulty would be in figuring  
out what we would need to preserve. Ideally someone implements this in  
a nightly and figures it out.


3) We can drop the concept of Attr being an object altogether. I do not  
think this is doable compatibility-wise, but not having  
Node.attributes, Attr, and just using  
getAttribute/getAttributeNS/setAttribute/setAttributeNS would be very  
nice complexity-wise.


If there is anything else I have not considered that can we try out  
please mention it! Any input on this is much appreciated.



My preference would be to simplify as much as we can get away with  
consistent with Web compatibility, all the way up to removing Attr nodes  
entirely if we can.


I do not know the Web compat impact of different options though.


 at one  
time made use of attr_node.firstChild.nodeValue instead of attr_node.value  
and used to break in Opera since Opera didn't support that. Opera was  
fixed so that worked (as quite a few users complained about that site).


The site might still require that.

I think it was in  
 in  
models_Base_Data.prototype.getText where other code was using that  
function not just on regular text nodes but Attr text nodes to get the  
attribute's value. I'm not sure if the code has changed since I last  
checked in Jan or 2008 though.


At the time, I made  
 to test some  
things with Attr nodes. (Note that the description on that page is  
outdated.)


--
Michael