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 <jia...@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 <le...@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 <jia...@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 >>> >>> >>> >> >