[webkit-dev] Support sending multiple files via XMLHttpRequest.send()

Darin Fisher darin at chromium.org
Tue Sep 8 23:17:13 PDT 2009

On Tue, Sep 8, 2009 at 11:11 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> On Sep 8, 2009, at 10:49 PM, Darin Fisher wrote:
> On Tue, Sep 8, 2009 at 6:22 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On Sep 8, 2009, at 6:16 PM, Jian Li wrote:
>> In WebKit, XMLHttpRequest.send() supports sending single file. It would be
>> better if we can support sending multiple files, like FileList (see bug
>> 25923 <https://bugs.webkit.org/show_bug.cgi?id=25923>).
>> In addition, XMLHttpRequest.send() only sends the raw content of the file,
>> without including the multipart boundary separators (see bug 26979<https://bugs.webkit.org/show_bug.cgi?id=26979>
>> ).
>> To resolve these issues, we can enhance XMLHttpRequest.send() to support a
>> FileList object and add multipart boundary separators support.
>> Or, the other simpler way (thanks for suggestion from Darin Fisher) is to
>> extend XMLHttpRequest.send() to take an array of items. Each of item could
>> either be a string or a file reference. The web application is responsible
>> to generate the miultipart 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?
>> I'd suggest proposing these ideas to the W3C Web Apps Working Group. I am
>> sure people there will have opinions. I'd like our approach here to be
>> aligned with other browsers.
>> Personally, I think the ability to mix strings and files is most useful,
>> thus I like the array approach. However, it would require defining what
>> happens to array elements that are not either a string or a File object.
> Wouldn't an implicit toString be appropriate?  We may even wish to allow
> the array to include Document references for completeness.
> Implicit toString is not the right behavior for File. I'm wondering if
> there are other current or future types for which it is not appropriate. If
> we did allow Documents or other DOM nodes, then we would probably want to
> serialize to markup instead of using toString, which would just result in
> "[object Document]". Canvas ImageData is another potential candidate for
> uploading, since uploading the image as binary data is probably
> more efficient than doing so as a data: URL. There's lots of possibilities
> here - probably best to discuss further on public-webapps.
> Regards,
> Maciej
Ah, good point.  I vote for being strict then.  That way there is room to
extend this to other types in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090908/d8148b85/attachment.html>

More information about the webkit-dev mailing list