Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Tue, 17 Nov 2009 18:31:51 -0200, Maciej Stachowiak m...@apple.com wrote: According to HTTP, I think sending no Content-Type more strongly indicates that you don't know the type. In particular, missing content type gives the recipient license to sniff the content. Ok, for Blob by default no Content-Type is included by the user agent unless Blob is a File and mediaType is non-empty and the author has not set a Content-Type header. If that is all true Content-Type is set to the value of mediaType. This has been changed in the editor's draft of XMLHttpRequest Level 2. -- Anne van Kesteren http://annevankesteren.nl/
Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Tue, Nov 10, 2009 at 7:48 AM, Jonas Sicking jo...@sicking.cc wrote: Yay! On Tue, Nov 10, 2009 at 4:06 PM, Anne van Kesteren ann...@opera.com wrote: WebKit presently supports sending File. It does not support FileData yet. Is Content-Type set to anything specific if the author has not set it? // FIXME: Should we set a Content-Type if one is not set. ^^^ looks like it presently depends on the web page setting the C-T header manually :-/ I think that should be fixed to be based on the system's knowledge of the file's mime type. So far I have only added support for Blob (the new FileData) of these two and set the Content-Type to application/octet-stream if not provided by the Web author. Should I also add File and set the Content-Type to File.mediaType? I definitely think so yes. Agreed. Same thing for the send() function. On a separate note, is sending application/octet-stream really better than simply sending no Content-Type header at all when sending a Blob (or a File with empty mediaType)? I think it is probably wise to default to sending a content type that explicitly says i don't know the type on the grounds that being explicit is better than not. -Darin
Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Nov 17, 2009, at 10:32 AM, Darin Fisher wrote: On Tue, Nov 10, 2009 at 7:48 AM, Jonas Sicking jo...@sicking.cc wrote: Yay! On Tue, Nov 10, 2009 at 4:06 PM, Anne van Kesteren ann...@opera.com wrote: WebKit presently supports sending File. It does not support FileData yet. Is Content-Type set to anything specific if the author has not set it? // FIXME: Should we set a Content-Type if one is not set. ^^^ looks like it presently depends on the web page setting the C- T header manually :-/ I think that should be fixed to be based on the system's knowledge of the file's mime type. So far I have only added support for Blob (the new FileData) of these two and set the Content-Type to application/octet-stream if not provided by the Web author. Should I also add File and set the Content-Type to File.mediaType? I definitely think so yes. Agreed. Same thing for the send() function. On a separate note, is sending application/octet-stream really better than simply sending no Content-Type header at all when sending a Blob (or a File with empty mediaType)? I think it is probably wise to default to sending a content type that explicitly says i don't know the type on the grounds that being explicit is better than not. According to HTTP, I think sending no Content-Type more strongly indicates that you don't know the type. In particular, missing content type gives the recipient license to sniff the content. Regards, Maciej
Re: Proposal for sending multiple files via XMLHttpRequest.send()
I added support for Blob and FormData to XMLHttpRequest Level 2 also based on the discussion at the F2F: http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ More comments below. On Tue, 20 Oct 2009 10:28:57 -0700, Darin Fisher da...@chromium.org wrote: Sorry... I just meant that I need to read up on discussions about octet-array support before I can comment ;-) See the email from Maciej to public-script-coord and es-discuss. WebKit presently supports sending File. It does not support FileData yet. Is Content-Type set to anything specific if the author has not set it? // FIXME: Should we set a Content-Type if one is not set. ^^^ looks like it presently depends on the web page setting the C-T header manually :-/ I think that should be fixed to be based on the system's knowledge of the file's mime type. So far I have only added support for Blob (the new FileData) of these two and set the Content-Type to application/octet-stream if not provided by the Web author. Should I also add File and set the Content-Type to File.mediaType? Does it make a straight copy of the file or can modifying the file cause potential problems? Modifying the file can cause potential problems. The same is true of ordinary HTML form submissions. I don't think we should spec this behavior. HTML5 should probably be more explicit about this. I used the multipart/form-data algorithm that HTML5 defines. (It mostly defers to RFC2388.) After TPAC means the week of November 9. Does that work? Sure. We might start on things sooner, but it doesn't mean it can't be revised. Do you have a demo implementation already? :-) -- Anne van Kesteren http://annevankesteren.nl/
Re: Proposal for sending multiple files via XMLHttpRequest.send()
Yay! On Tue, Nov 10, 2009 at 4:06 PM, Anne van Kesteren ann...@opera.com wrote: WebKit presently supports sending File. It does not support FileData yet. Is Content-Type set to anything specific if the author has not set it? // FIXME: Should we set a Content-Type if one is not set. ^^^ looks like it presently depends on the web page setting the C-T header manually :-/ I think that should be fixed to be based on the system's knowledge of the file's mime type. So far I have only added support for Blob (the new FileData) of these two and set the Content-Type to application/octet-stream if not provided by the Web author. Should I also add File and set the Content-Type to File.mediaType? I definitely think so yes. Same thing for the send() function. On a separate note, is sending application/octet-stream really better than simply sending no Content-Type header at all when sending a Blob (or a File with empty mediaType)? / Jonas
re: Proposal for sending multiple files via XMLHttpRequest.send()
I'd like to revive the Proposal for sending multiple files via XMLHttpRequest.send() thread started by Jian Li back in September. As pointed out on that thread, sending a JS array of strings and File references isn't going to fly due to an array of strings already having meaning. That thread concluded with Jonas Sicking saying: I definitely think that we need to add some way of sending a stream that is a concatenation of strings, binary data, and files, without requiring the files to be read. What should this look like? Should there be a new global constructor for an object that supports methods like appendText and appendFile? Like this: var data = new UploadData; data.appendText(foo); data.appendFile(fileRef); xhr.send(data); I like the idea of creating a primitive that does not enforce any encoding. Thoughts? -Darin
Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Tue, 20 Oct 2009 08:55:21 +0200, Darin Fisher da...@chromium.org wrote: I'd like to revive the Proposal for sending multiple files via XMLHttpRequest.send() thread started by Jian Li back in September. As pointed out on that thread, sending a JS array of strings and File references isn't going to fly due to an array of strings already having meaning. That thread concluded with Jonas Sicking saying: I definitely think that we need to add some way of sending a stream that is a concatenation of strings, binary data, and files, without requiring the files to be read. What should this look like? Should there be a new global constructor for an object that supports methods like appendText and appendFile? Like this: var data = new UploadData; data.appendText(foo); data.appendFile(fileRef); xhr.send(data); I like the idea of creating a primitive that does not enforce any encoding. Thoughts? I think for a lot of authors the easiest would be easiest if it was in the form of multipart/form-data as then they do not have to do anything special to get the data on the server. -- Anne van Kesteren http://annevankesteren.nl/
Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Tue, Oct 20, 2009 at 1:37 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 20 Oct 2009 08:55:21 +0200, Darin Fisher da...@chromium.org wrote: I'd like to revive the Proposal for sending multiple files via XMLHttpRequest.send() thread started by Jian Li back in September. As pointed out on that thread, sending a JS array of strings and File references isn't going to fly due to an array of strings already having meaning. That thread concluded with Jonas Sicking saying: I definitely think that we need to add some way of sending a stream that is a concatenation of strings, binary data, and files, without requiring the files to be read. What should this look like? Should there be a new global constructor for an object that supports methods like appendText and appendFile? Like this: var data = new UploadData; data.appendText(foo); data.appendFile(fileRef); xhr.send(data); I like the idea of creating a primitive that does not enforce any encoding. Thoughts? I think for a lot of authors the easiest would be easiest if it was in the form of multipart/form-data as then they do not have to do anything special to get the data on the server. That does address the primary use case, but do you really think that we should rule out the use case of custom encodings? (At least for Gecko and WebKit, it is really trivial to support the more free-form interface since the underlying network layers speak in terms of a list of strings and file references.) If we do go the more specific route, then it could look like this: var data = new FormData; data.appendText(name1, value); data.appendFile(name2, fileData); xhr.send(data); The UA could populate the filename attribute of the Content-Disposition header based on the given fileRef. Same goes for the Content-Type header. Hmm... this may indeed be a good way to go since I don't think the proposed FileData ( http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html#FileData-if) interface includes a name attribute. -Darin -- Anne van Kesteren http://annevankesteren.nl/
Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Tue, 20 Oct 2009 10:56:47 +0200, Darin Fisher da...@chromium.org wrote: On Tue, Oct 20, 2009 at 1:37 AM, Anne van Kesteren ann...@opera.com wrote: I think for a lot of authors the easiest would be easiest if it was in the form of multipart/form-data as then they do not have to do anything special to get the data on the server. That does address the primary use case, but do you really think that we should rule out the use case of custom encodings? (At least for Gecko and WebKit, it is really trivial to support the more free-form interface since the underlying network layers speak in terms of a list of strings and file references.) I do not want to rule anything out, but a request I repeatedly hear is duplicating form functionality with XMLHttpRequest. Support for multipart/form-data furthermore is extremely widespread and resembles quite closely what is desired so it seems good to use it. If eventually we get native support for octet-arrays and all we can at that point add the ability to XMLHttpRequest so you can send anything you want. If we do go the more specific route, then it could look like this: var data = new FormData; data.appendText(name1, value); data.appendFile(name2, fileData); xhr.send(data); The UA could populate the filename attribute of the Content-Disposition header based on the given fileRef. Same goes for the Content-Type header. Hmm... this may indeed be a good way to go since I don't think the proposed FileData ( http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html#FileData-if) interface includes a name attribute. This looks reasonable to me. I suppose we also want support passing File[Data] and FileList directly as I believe WebKit might have already added. Do you happen to know the implementation details? (I'm planning to wait with defining this until at least after TPAC. I expect more discussion to happen there and I also want to keep focus on the CSSOM before switching tasks again. It would be good to have most of the details before than though.) -- Anne van Kesteren http://annevankesteren.nl/
Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Tue, 20 Oct 2009 18:27:36 +0200, Darin Fisher da...@chromium.org
wrote:
On Tue, Oct 20, 2009 at 4:31 AM, Anne van Kesteren ann...@opera.com
wrote:
If eventually we get native support for octet-arrays and all we can at
that point add the ability to XMLHttpRequest so you can send anything
you want.
Hmm, OK
If you envision things differently, by all means say so :-)
If we do go the more specific route, then it could look like this:
var data = new FormData;
data.appendText(name1, value);
data.appendFile(name2, fileData);
xhr.send(data);
The UA could populate the filename attribute of the Content-Disposition
header based on the given fileRef. Same goes for the Content-Type
header.
Hmm... this may indeed be a good way to go since I don't think the
proposed
FileData (
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html#FileData-if
)
interface includes a name attribute.
This looks reasonable to me.
I suppose we also want support passing File[Data] and FileList directly
as I believe WebKit might have already added. Do you happen to know the
implementation details?
WebKit presently supports sending File. It does not support FileData
yet.
Is Content-Type set to anything specific if the author has not set it? I
assume what is being transferred is the file data, octet-for-octet, as it
is represented on the disk? Does it make a straight copy of the file or
can modifying the file cause potential problems?
I'm not sure about supporting FileList. If it were to be encoded using
multipart/form-data, then how would the form field names be chosen?
Would they just be excluded from the encoding?
If we have something like the FormData type proposed above, then we
wouldn't need to support sending a FileList. People could just iterate
a FileList
and call appendFile for each element of the FileList.
True.
(I'm planning to wait with defining this until at least after TPAC. I
expect more discussion to happen there and I also want to keep focus on
the CSSOM before switching tasks again. It would be good to have most
of the
details before than though.)
OK
I'm interested in having a WebKit implementation for this soon.
After TPAC means the week of November 9. Does that work?
Meanwhile my basic idea based on your proposal is:
[Constructor] interface FormData {
void append(DOMString name, DOMString value);
void append(DOMString name, FileData value);
}
Then when send() is invoked with a FormData object I assume the easiest
would be to make a copy of the object serialize it per the rules of RFC
2388 (encoding DOMString values as UTF-8) and done.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Tue, 20 Oct 2009 18:47:59 +0200, Anne van Kesteren ann...@opera.com wrote: On Tue, 20 Oct 2009 18:27:36 +0200, Darin Fisher da...@chromium.org wrote: On Tue, Oct 20, 2009 at 4:31 AM, Anne van Kesteren ann...@opera.com wrote: If eventually we get native support for octet-arrays and all we can at that point add the ability to XMLHttpRequest so you can send anything you want. Hmm, OK If you envision things differently, by all means say so :-) So, I envision things a bit differently from Anne (as he and I have discussed in relation to Progress events). If we do go the more specific route, then it could look like this: var data = new FormData; data.appendText(name1, value); data.appendFile(name2, fileData); xhr.send(data); The UA could populate the filename attribute of the Content-Disposition header based on the given fileRef. Same goes for the Content-Type header. ... My rough idea is that you have a set of things being sent, as per appcache. You collect them somehow (I have no particular opinion on formdata or something else), and send them, as transaction that sends a bunch of objects. The thinking behind adding loadedItems and totalItems to progress events (as Anne says, maybe having the existing simple interface and a longer one that inherits and adds the extra attributes is a good idea) was that you could then provide progress information both on a what object has gone basis, and how much of this object has gone. The way I came up with effectively supposes an array of items, and the loadedItems (where present) acts as an index to the array. A natural consequence of this is that if somehow you are sending the objects out of order, you still give progress information on a per-object basis. (This wasn't actually a goal, it just happens that way). The point of ISSUE-107 was that I envisaged sending a load event for each object (as currently written appcache sends a progress event) when it is loaded, with a single loadstart and a single loadend for the entire transaction. Optionally, you can send a progress event where part of an object has been transmitted. Obviously this is a change to appcache - albeit I believe a relatively small one, substituting the current events sent for slightly different ones. In principle you would add the size of the object, as the loaded attribute of the load event sent, but in practice that's probably not necessary (note to self - the spec doesn't say what you put. Maybe it should allow a dummy value, but maybe not...). A consequence of this model is that when you get the events you can find out which things got shifted, and decide whether to go back and try again if something dropped. I have repeatedly seen, because it takes nothing more than looking, pages come through apparently missing an icon or something which doesn't matter, in which case it would be useful if the app started working and just tried to refetch the missing icon in the background. If some critical script is missing, you need to go back and get it. As Anne says, this is potentially more complicated - but nothing obliges you to use it. If you get any error or abort instead of a load you can simply insist on reloading until you have everything. But it seems to me this provides authors with the ability to write applications that are more robust on flaky networks (or dealing with flaky servers), if they choose to do so. As far as I can tell it would be feasible to implement this without changing Anne's proposal. At the same time, this would allow for other APIs (appcache5, or fetchMail, or whatever) to use progress events more or less as they are in the new editor's draft [1]. However, this week I will talk to the implementors at Opera and see what they think - and I hope also to get feedback from Hixie on this. [1] http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.32 thoughts? cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Proposal for sending multiple files via XMLHttpRequest.send()
How is supposed the web application to detect that the browser supports this feature? Maybe instead of overloaded send, we should create new method sendFile(File) and sendFiles(File[]). And between the two approaches, the first one is simpler, but the second one allows to send the files one each time and add other form data in the request. Maybe sendFiles(File[], [Strings[]])?
Re: Proposal for sending multiple files via XMLHttpRequest.send()
What I think we really want is a script-only means of sending multipart
form-data encoding POSTs that contain a mix of file- parts and binary-parts
(in addition to the ability to send the raw contents of a file).
* script-only, so these POSTs can be performed in workers
* multipart form-data, its the defacto standard
The Gears stab at this was BlobBuilder, which let developers compose
something with a mix of utf8 encoded strings and binary ile data, and
Gears.HttpRequest.send(blob). Developers were left to their own devices to
produce a valid mulitpart form-data encoded blob by manually stitching
together the parts with appropiate boundaries and such, and then setting the
content-type on the request properly prior to sending. Somewhat tedious for
developers but it worked.
The Gears team had considered expressing things as an array with a mix of
strings and Blobs, and then sending the array as well, but shied away from
that because we .send([]) already has a meaning (as has been pointed out in
this thread).
Another way to expose this capability in a script-only way could be the
introduction of a new object for this purpose.
class FormData {
addString(name, value);
addFile(name, file); // maybe optional params for additional
content-disposition headers?
}
xhr.send(formData);
2009/9/12 Alfonso Martínez de Lizarrondo aml...@gmail.com
Since XMLHttpRequest spec has already added the overload for
send(document),
why not just adding more overload for file and array of items? IMHO,
having
similar send*** methods, like sendFile, together with overloads of send()
might make the API more complicated.
If the browser doesn't provide any system to detect that it supports
this feature, then the only way to enable it is to do UA sniffing, and
I thought that everyone agreed that this is bad because when the code
is deployed it must be updated for each new browser that implements
this API.
I wrote about my point of view about this kind of features in
http://alfonsoml.blogspot.com/2009/08/upload-progress-for-firefox-35.html
As I said there, if other browser implements that API the code will
work automatically for them. It's not a problem to add new code to
support a new API, but make it work based on UA it isn't nice.
Re: Proposal for sending multiple files via XMLHttpRequest.send()
2009/9/14 Michael Nordman micha...@google.com: What I think we really want is a script-only means of sending multipart form-data encoding POSTs that contain a mix of file- parts and binary-parts (in addition to the ability to send the raw contents of a file). * script-only, so these POSTs can be performed in workers * multipart form-data, its the defacto standard The Gears stab at this was BlobBuilder, which let developers compose something with a mix of utf8 encoded strings and binary ile data, and Gears.HttpRequest.send(blob). Developers were left to their own devices to produce a valid mulitpart form-data encoded blob by manually stitching together the parts with appropiate boundaries and such, and then setting the content-type on the request properly prior to sending. Somewhat tedious for developers but it worked. I definitely think that we need to add some way of sending a stream that is a concatenation of strings, binary data, and files, without requiring the files to be read. Once we have that, there's a question of if we need to add convenience features for specific formats, such as multipart form-data and/or JSON. / Jonas
Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Mon, Sep 14, 2009 at 1:26 PM, Jonas Sicking jo...@sicking.cc wrote: 2009/9/14 Michael Nordman micha...@google.com: What I think we really want is a script-only means of sending multipart form-data encoding POSTs that contain a mix of file- parts and binary-parts (in addition to the ability to send the raw contents of a file). * script-only, so these POSTs can be performed in workers * multipart form-data, its the defacto standard The Gears stab at this was BlobBuilder, which let developers compose something with a mix of utf8 encoded strings and binary ile data, and Gears.HttpRequest.send(blob). Developers were left to their own devices to produce a valid mulitpart form-data encoded blob by manually stitching together the parts with appropiate boundaries and such, and then setting the content-type on the request properly prior to sending. Somewhat tedious for developers but it worked. I definitely think that we need to add some way of sending a stream that is a concatenation of strings, binary data, and files, without requiring the files to be read. Once we have that, there's a question of if we need to add convenience features for specific formats, such as multipart form-data and/or JSON. Agreed... and gears stopped at the first milestone you described without adding the convenience classes. / Jonas
Re: Proposal for sending multiple files via XMLHttpRequest.send()
Thank you for all your great feedbacks. Yes, the first approach is simpler and it requites far less work from the author and thus less error prone. However, I think the second approach does provide more flexibilities that might fit for the different data assembling and sending purpose. The author can use it to upload multiple attached files, save a set of client generated items, or even send any combinations of string data and file data. For example, the presentation web application wants to save a set of client generated slides to the server. Some of slides include attached files, like a video clip. It will be much easier for the author to send all the data to the server via the second approach: var payload = new Array; payload.push(header_for_slide1); payload.push(data_for_slide1); payload.push(header_for_slide2); payload.push(data_for_slide2); payload.push(attached_file1_for_slide2); payload.push(attached_file2_for_slide2); ... xhr.send(payload); Since XMLHttpRequest spec has already added the overload for send(document), why not just adding more overload for file and array of items? IMHO, having similar send*** methods, like sendFile, together with overloads of send() might make the API more complicated. 2009/9/11 Yaar Schnitman y...@chromium.org How is supposed the web application to detect that the browser supports this feature? Maybe instead of overloaded send, we should create new method sendFile(File) and sendFiles(File[]). And between the two approaches, the first one is simpler, but the second one allows to send the files one each time and add other form data in the request. Maybe sendFiles(File[], [Strings[]])?
Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Fri, Sep 11, 2009 at 11:46 PM, Jian Li jia...@chromium.org wrote: Thank you for all your great feedbacks. Yes, the first approach is simpler and it requites far less work from the author and thus less error prone. However, I think the second approach does provide more flexibilities that might fit for the different data assembling and sending purpose. The author can use it to upload multiple attached files, save a set of client generated items, or even send any combinations of string data and file data. For example, the presentation web application wants to save a set of client generated slides to the server. Some of slides include attached files, like a video clip. It will be much easier for the author to send all the data to the server via the second approach: var payload = new Array; payload.push(header_for_slide1); payload.push(data_for_slide1); payload.push(header_for_slide2); payload.push(data_for_slide2); payload.push(attached_file1_for_slide2); payload.push(attached_file2_for_slide2); ... xhr.send(payload); Since XMLHttpRequest spec has already added the overload for send(document), why not just adding more overload for file and array of items? IMHO, having similar send*** methods, like sendFile, together with overloads of send() might make the API more complicated. It does seem useful to allow sending textual data combined with file data. So if you do something like: xhr.send([foo, file, bar]); then that would send the string foo, concatenated with the data from the file, and then finally the string bar. The string data would be UTF8 encoded. In the future we can also add support for ByteArrays (or whatever they'll end up being called) combined with anything else. However, a problem is that xhr.send([foo, bar]); is defined to send foo,bar. It would seem weird if array handling changes just one of the items in the array is a file. One possible solution is to add additional 'send' methods. / Jonas
Re: Proposal for sending multiple files via XMLHttpRequest.send()
Since XMLHttpRequest spec has already added the overload for send(document), why not just adding more overload for file and array of items? IMHO, having similar send*** methods, like sendFile, together with overloads of send() might make the API more complicated. If the browser doesn't provide any system to detect that it supports this feature, then the only way to enable it is to do UA sniffing, and I thought that everyone agreed that this is bad because when the code is deployed it must be updated for each new browser that implements this API. I wrote about my point of view about this kind of features in http://alfonsoml.blogspot.com/2009/08/upload-progress-for-firefox-35.html As I said there, if other browser implements that API the code will work automatically for them. It's not a problem to add new code to support a new API, but make it work based on UA it isn't nice.
Re: Proposal for sending multiple files via XMLHttpRequest.send()
Mozilla has something similar already called sendAsBinary though it takes a string not an array https://developer.mozilla.org/en/XMLHttpRequest#sendAsBinary%28%29 On Thu, Sep 10, 2009 at 7:28 PM, Anne van Kesteren ann...@opera.com wrote: On Thu, 10 Sep 2009 03:12:52 +0200, Jian Li jia...@chromium.org wrote: There has already been a discussion on extending XMLHttpRequest.send() to take a File object. Could we also consider enhancing it further to support sending multiple files, like a FileList from the drag and drop. We could make XMLHttpRequest.send() take a FileList object and let the browser add multipart boundary separators automatically. Or, the other simpler way, thanks to Darin's suggestion, is to extend XMLHttpRequest.send() to take an array of items. Each of item could be either a string or a file reference strictly. The web application is responsible to generate the multipart enevelop like the following: var payload = new Array; payload.push(header1); payload.push(file1); payload.push(footer1); ... xhr.send(payload); How do you guys think about these approaches? The first seems a lot less error-prone for authors. I think we should go with that. -- Anne van Kesteren http://annevankesteren.nl/
Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Fri, 11 Sep 2009 02:28:26 +0200, Ryan Seddon seddon.r...@gmail.com wrote: Mozilla has something similar already called sendAsBinary though it takes a string not an array https://developer.mozilla.org/en/XMLHttpRequest#sendAsBinary%28%29 Besides that I think that representing octets by a DOMString is the wrong way to go for Web Platform APIs the original request was about sending a list of File objects. sendAsBinary does not do that per the documentation. -- Anne van Kesteren http://annevankesteren.nl/
Re: Proposal for sending multiple files via XMLHttpRequest.send()
2009/9/10 Jian Li jia...@chromium.org: There has already been a discussion on extending XMLHttpRequest.send() to take a File object. Could we also consider enhancing it further to support sending multiple files, like a FileList from the drag and drop. We could make XMLHttpRequest.send() take a FileList object and let the browser add multipart boundary separators automatically.. Or, the other simpler way, thanks to Darin's suggestion, is to extend XMLHttpRequest.send() to take an array of items. Each of item could be either a string or a file reference strictly. The web application is responsible to generate the multipart enevelop like the following: var payload = new Array; payload.push(header1); payload.push(file1); payload.push(footer1); ... xhr.send(payload); How do you guys think about these approaches? Thanks, Jian How is supposed the web application to detect that the browser supports this feature? And between the two approaches, the first one is simpler, but the second one allows to send the files one each time and add other form data in the request.
Proposal for sending multiple files via XMLHttpRequest.send()
There has already been a discussion on extending XMLHttpRequest.send() to take a File object. Could we also consider enhancing it further to support sending multiple files, like a FileList from the drag and drop. We could make XMLHttpRequest.send() take a FileList object and let the browser add multipart boundary separators automatically. Or, the other simpler way, thanks to Darin's suggestion, is to extend XMLHttpRequest.send() to take an array of items. Each of item could be either a string or a file reference strictly. The web application is responsible to generate the multipart enevelop like the following: var payload = new Array; payload.push(header1); payload.push(file1); payload.push(footer1); ... xhr.send(payload); How do you guys think about these approaches? Thanks, Jian
Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Thu, 10 Sep 2009 03:12:52 +0200, Jian Li jia...@chromium.org wrote: There has already been a discussion on extending XMLHttpRequest.send() to take a File object. Could we also consider enhancing it further to support sending multiple files, like a FileList from the drag and drop. We could make XMLHttpRequest.send() take a FileList object and let the browser add multipart boundary separators automatically. Or, the other simpler way, thanks to Darin's suggestion, is to extend XMLHttpRequest.send() to take an array of items. Each of item could be either a string or a file reference strictly. The web application is responsible to generate the multipart enevelop like the following: var payload = new Array; payload.push(header1); payload.push(file1); payload.push(footer1); ... xhr.send(payload); How do you guys think about these approaches? The first seems a lot less error-prone for authors. I think we should go with that. -- Anne van Kesteren http://annevankesteren.nl/
