Re: FormData with sliced Blob

To be even safer, I'd remove dashes from it... I never knew why GUIDs have
those dashes - to make them easier to memorize? :-)

Seriously though, it would be nice to have XHR2 spec to have these details
spelled out, especially mime type (I think David meant
application/octet-stream)

Dmitry

On Mon, Mar 22, 2010 at 5:26 PM, Jian Li <jianli@google.com> wrote:

> To be safe, probably UA can choose to create the unique name from the GUID,
> like blob-5597cb2e-74fb-479a-81e8-10679c523118.
>
>
> On Mon, Mar 22, 2010 at 4:43 PM, David Levin <levin@google.com> wrote:
>
>> What about using a filename that is unique with repect to files sent in
>> that FormData (but it is up to the UA)? For example, a UA may choose to do
>> Blob1, Blob2, etc. For the content-type, application/octet-string seems most
>> fitting.
>>
>> Here's the result applied to your example:
>>    ------SomeBoundary...
>>    Content-Disposition: form-data; name="file"; filename="Blob1"
>>    Content-Type: application/octet-string
>>
>> dave
>>
>>
>> On Fri, Mar 19, 2010 at 6:25 PM, Jian Li <jianli@google.com> wrote:
>>
>>> Hi,
>>>
>>> I have questions regarding sending FormData with sliced files. When we
>>> send a FormData with a regular file, we send out the multipart data for this
>>> file, like the following:
>>>
>>>    ------SomeBoundary...
>>>    Content-Disposition: form-data; name="file"; filename="test.js"
>>>    Content-Type: application/x-javascript
>>>    ...
>>>
>>> However, when it is sliced into a blob, it does not have the file name
>>> and type information any more. I am wondering what we should send.  Should
>>> we just not provide the filename and Content-Type information?
>>>
>>> Thanks,
>>>
>>> Jian
>>>
>>>
>>>
>>
>