Re: Proposal for sending multiple files via XMLHttpRequest.send()

On Tue, Oct 20, 2009 at 9:47 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Tue, 20 Oct 2009 18:27:36 +0200, Darin Fisher <darin@chromium.org>
> wrote:
>
>> On Tue, Oct 20, 2009 at 4:31 AM, Anne van Kesteren <annevk@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 :-)



Sorry...  I just meant that I need to read up on discussions about
octet-array support before I can comment ;-)



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


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



> I assume what is being transferred is the file data, octet-for-octet, as it
> is represented on the disk?


Yes.



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



>
>
>
>  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?
>
>
Sure.  We might start on things sooner, but it doesn't mean it can't be
revised.



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


Yup, sounds good.  I like the overloaded "append" methods.

Thanks,
-Darin



>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>