Re: Proposal for an extension XMLHttpRequest to allow sending files
Hi Sam,
This seems like a reasonable extension to me.
A colleague asks Are there any new security concerns by putting this
inside XHR, or is the assumption that we are not exposing anything new?
What are your thoughts on that question? I presume not exposing
anything new given this type of functionality is already provided
(e.g. form submission as mentioned below).
-Regards, Art Barstow
On Jul 17, 2008, at 4:14 PM, ext Sam Weinig wrote:
We would like to propose standardizing a way of using
XMLHttpRequest to send files to the server. We propose using a
similar (and compatible) API to the Blob based API proposed by
Google Gears (http://code.google.com/p/gears/wiki/
BlobWebAPIPropsal), but instead of sending Blob objects, the File
objects would be sent. This will allow the common act of uploading
files, now relegated to form submissions with an input
type=file, to have access to ProgressEvents and the ability to
abort mid way through.
As with the Blob API, this is reuses the File and FileList
interfaces exposed by Mozilla (see http://developer.mozilla.org/en/
docs/nsIDOMFile and http://developer.mozilla.org/en/docs/
nsIDOMFileList) in a compatible. We are not proposing a specific
way to get the contents of the files, but that would be a natural
future extension. Other potential future extensions would be
access to the icon associated with the file.
Objects implementing the HTMLInputElement interface must also
implement the FileHTMLInputElement interface.
interface FileHTMLInputElement {
readonly attribute FileList files;
};
The files attribute must return a FileList containing all the files
currently selected. This list is live, and therefore updates if
contents of the input element change.
interface FileList {
readonly attribute unsigned long length
[IndexGetter] File item(in unsigned long index);
};
Each item in the FileList is File, which is a token representation
of file on the system. The fileName attribute returns just the
name and not the complete path. The fileSize attribute returns the
size of the file in bytes.
interface File {
readonly attribute DOMString fileName;
readonly attribute unsigned long long fileSize;
};
Sending a File can be accomplished with an extension to
XMLHttpRequest that overrides the existing send() method.
Objects implementing the XMLHttpRequest interface must also
implement the FileXMLHttpRequest interface.
interface FileXMLHttpRequest {
void send(File data);
};
-Sam Weinig
Re: Proposal for an extension XMLHttpRequest to allow sending files
On Jul 28, 2008, at 10:45 AM, Jonas Sicking wrote: Arthur Barstow wrote: Hi Sam, This seems like a reasonable extension to me. A colleague asks Are there any new security concerns by putting this inside XHR, or is the assumption that we are not exposing anything new? What are your thoughts on that question? I presume not exposing anything new given this type of functionality is already provided (e.g. form submission as mentioned below). Yes, I believe that when we implemented a similar feature in mozilla (different API though) we came to the conclusion that it didn't expose anything significantly new. There were a few differences though: If the File object can be stored in an offline cache, this means that somebody could today be theoretically protected while inside a corporate firewall, as long as they always restart the browser before leaving that firewall. I.e. even if you were somehow tricked into choosing to upload a file, a corporate firewall could protect that data from ever reaching the server. However if the File object can be stored in a offline cache, such as localStore, then restarting the browser will not prevent this. I am not sure this is a real attack vector, as the only local storage provided are string based, so one could not store the File object itself. Same holds true if a File object can be used to directly read data out from the file. This would be the real vector. So while File upload through XHR on its own does not seem to cause any security issues. There are some theoretical attacks where it can be used in combination with other things. However at mozilla we did not consider these new attacks likely enough that it prevented us from implementing the feature. The main line of defense is the browser UI that lets you choose a file to upload. If that doesn't protect the user well enough, the user is in the vast majority of cases compromised anyway. Agreed. / Jonas - Sam
Re: Proposal for an extension XMLHttpRequest to allow sending files
On Jul 18, 2008, at 9:58 AM, Aaron Boodman wrote: On Thu, Jul 17, 2008 at 4:06 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Jul 17, 2008, at 3:53 PM, Aaron Boodman wrote: I have two minor concerns with this proposal, both in the cases where it differs from Gears: 1. Combining the concepts of 'large chunk of binary data' and 'file' seems unnecessarily coupled to me. It seems likely that in the future the first concept would be useful in the web api by itself. For example, in Gears, we have a xhr.responseBlob property. Having a fileName property here would not always make sense. I agree! But this proposal doesn't include a concept of 'large chunk of binary data', only a concept of 'file'. It just lets you send the file without first turning it into a chunk of binary data. We're not proposing that the File object should be a generic representation for any binary data, just that it should be sendable via XHR directly. So you're saying that in the future XHR.send() could be overloaded to take blob as an argument too? I guess another way to handle it would be with inheritance -- File could implement Blob, and then you could change XHR.send() to take Blob instead of File. Either of these are fine with me. XHR.send() already takes many things, so one extra overload is not a big deal. I can imagine a future design making File be a kind of Blob instead of having a Blob as in gears, but the idea is that we don't all have to agree on that now. 2. The slice() method seems important for the initial version, particularly if you are targeting the large upload use case. We use this to cut up a large file into smaller pieces so that they can be uploaded individually. This makes the upload resilient and also allows the UI to show progress on the upload. So far the other requests we have had for this functionality have not needed slicing capability, but nothing in our proposal precludes adding it (even adding it in a way that's identical to the Gears proposal would be possible). On Thu, Jul 17, 2008 at 4:32 PM, Sam Weinig [EMAIL PROTECTED] wrote: Upload progress is possible without manually slicing using the new upload progress events proposed in the XMLHttpRequest Level 2 spec. Sam's point is good. I forgot that we actually have this in Gears mainly for resumability of large uploads, not for progress (we have implemented upload progress too). I can understand this is less necessary for the initial version. I wonder if it is possible to make resumability more automatic, somewhat like the way If-Range is used to do resumable downloads. But manual slicing does seem like an ok solution. Regards, Maciej
Re: Proposal for an extension XMLHttpRequest to allow sending files
On Jul 17, 2008, at 1:23 PM, Aaron Boodman wrote:
Is the only difference from the Gears proposal the name of the object
(File) and the lack of reading APIs initially?
The Gears proposal has a File object too, as does Mozilla's extension.
We are proposing making the File object usable directly as an XHR
body, so that we can all support file upload through XHR interoperably
without first having to agree on the mechanisms for reading file
contents and representing binary data (which are different between
Gears and Mozilla).
File upload through XHR is useful even without a means to read the
data client-side, because combined with progress events it can provide
in-page progress UI with info for multiple files, which is quite a bit
better than what you get with form submission. Currently some web apps
use Flash for uploads solely to enable progress UI.
As Sam mentioned, overloading send() to take a File does not preclude
later overloading it to take a Blob or ByteArray or any other kind of
object representing raw data.
Regards,
Maciej
- a
On Thu, Jul 17, 2008 at 1:14 PM, Sam Weinig [EMAIL PROTECTED] wrote:
We would like to propose standardizing a way of using
XMLHttpRequest to send
files to the server. We propose using a similar (and compatible)
API to the
Blob based API proposed by Google Gears
(http://code.google.com/p/gears/wiki/BlobWebAPIPropsal), but
instead of
sending Blob objects, the File objects would be sent. This will
allow the
common act of uploading files, now relegated to form submissions
with an
input type=file, to have access to ProgressEvents and the
ability to
abort mid way through.
As with the Blob API, this is reuses the File and FileList interfaces
exposed by Mozilla
(see http://developer.mozilla.org/en/docs/nsIDOMFile and
http://developer.mozilla.org/en/docs/nsIDOMFileList)
in a compatible. We are not proposing a specific way to get the
contents of
the files, but that would be a natural future extension. Other
potential
future extensions would be access to the icon associated with the
file.
Objects implementing the HTMLInputElement interface must also
implement the
FileHTMLInputElement interface.
interface FileHTMLInputElement {
readonly attribute FileList files;
};
The files attribute must return a FileList containing all the files
currently selected. This list is live, and therefore updates if
contents of
the input element change.
interface FileList {
readonly attribute unsigned long length
[IndexGetter] File item(in unsigned long index);
};
Each item in the FileList is File, which is a token representation
of file
on the system. The fileName attribute returns just the name and
not the
complete path. The fileSize attribute returns the size of the file
in
bytes.
interface File {
readonly attribute DOMString fileName;
readonly attribute unsigned long long fileSize;
};
Sending a File can be accomplished with an extension to
XMLHttpRequest that
overrides the existing send() method.
Objects implementing the XMLHttpRequest interface must also implement
the FileXMLHttpRequest interface.
interface FileXMLHttpRequest {
void send(File data);
};
-Sam Weinig
Re: Proposal for an extension XMLHttpRequest to allow sending files
On Thu, Jul 17, 2008 at 3:41 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: The Gears proposal has a File object too, as does Mozilla's extension. We are proposing making the File object usable directly as an XHR body, so that we can all support file upload through XHR interoperably without first having to agree on the mechanisms for reading file contents and representing binary data (which are different between Gears and Mozilla). Right, I see the difference now. It is basically: Gears proposal: xhr.send(inputElement.files[0].contents); WebKit proposal: xhr.send(inputElement.files[0]); File upload through XHR is useful even without a means to read the data client-side, because combined with progress events it can provide in-page progress UI with info for multiple files, which is quite a bit better than what you get with form submission. Currently some web apps use Flash for uploads solely to enable progress UI. Yup, this is the main reason we proposed this API. Reading the data is secondary and is not implemented in Gears today or planned for the near term. I have two minor concerns with this proposal, both in the cases where it differs from Gears: 1. Combining the concepts of 'large chunk of binary data' and 'file' seems unnecessarily coupled to me. It seems likely that in the future the first concept would be useful in the web api by itself. For example, in Gears, we have a xhr.responseBlob property. Having a fileName property here would not always make sense. 2. The slice() method seems important for the initial version, particularly if you are targeting the large upload use case. We use this to cut up a large file into smaller pieces so that they can be uploaded individually. This makes the upload resilient and also allows the UI to show progress on the upload. - a
Re: Proposal for an extension XMLHttpRequest to allow sending files
On Jul 17, 2008, at 3:53 PM, Aaron Boodman wrote: On Thu, Jul 17, 2008 at 3:41 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: The Gears proposal has a File object too, as does Mozilla's extension. We are proposing making the File object usable directly as an XHR body, so that we can all support file upload through XHR interoperably without first having to agree on the mechanisms for reading file contents and representing binary data (which are different between Gears and Mozilla). Right, I see the difference now. It is basically: Gears proposal: xhr.send(inputElement.files[0].contents); WebKit proposal: xhr.send(inputElement.files[0]); File upload through XHR is useful even without a means to read the data client-side, because combined with progress events it can provide in-page progress UI with info for multiple files, which is quite a bit better than what you get with form submission. Currently some web apps use Flash for uploads solely to enable progress UI. Yup, this is the main reason we proposed this API. Reading the data is secondary and is not implemented in Gears today or planned for the near term. I have two minor concerns with this proposal, both in the cases where it differs from Gears: 1. Combining the concepts of 'large chunk of binary data' and 'file' seems unnecessarily coupled to me. It seems likely that in the future the first concept would be useful in the web api by itself. For example, in Gears, we have a xhr.responseBlob property. Having a fileName property here would not always make sense. I agree! But this proposal doesn't include a concept of 'large chunk of binary data', only a concept of 'file'. It just lets you send the file without first turning it into a chunk of binary data. We're not proposing that the File object should be a generic representation for any binary data, just that it should be sendable via XHR directly. 2. The slice() method seems important for the initial version, particularly if you are targeting the large upload use case. We use this to cut up a large file into smaller pieces so that they can be uploaded individually. This makes the upload resilient and also allows the UI to show progress on the upload. So far the other requests we have had for this functionality have not needed slicing capability, but nothing in our proposal precludes adding it (even adding it in a way that's identical to the Gears proposal would be possible). Regards, Maciej
Re: Proposal for an extension XMLHttpRequest to allow sending files
2. The slice() method seems important for the initial version, particularly if you are targeting the large upload use case. We use this to cut up a large file into smaller pieces so that they can be uploaded individually. This makes the upload resilient and also allows the UI to show progress on the upload. Upload progress is possible without manually slicing using the new upload progress events proposed in the XMLHttpRequest Level 2 spec. -Sam
