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

[Darin Fisher]

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.
-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090908/d8148b85/attachment.html>