Re: FormData with sliced Blob
On Tue, 23 Mar 2010 22:22:37 +0100, Darin Fisher da...@chromium.org wrote: Why couldn't FormData.append(Blob) provide optional parameters to allow the caller to specify the name and type? Why wouldn't you provide a File object instead then? It seems a lot of use cases here and elsewhere would be addressed by having a way to get a File out of a Blob. -- Anne van Kesteren http://annevankesteren.nl/
Re: FormData with sliced Blob
On Wed, Mar 24, 2010 at 2:55 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 23 Mar 2010 22:22:37 +0100, Darin Fisher da...@chromium.org wrote: Why couldn't FormData.append(Blob) provide optional parameters to allow the caller to specify the name and type? Why wouldn't you provide a File object instead then? It seems a lot of use cases here and elsewhere would be addressed by having a way to get a File out of a Blob. That's a very interesting idea. I hadn't considered the possibility of creating a File from a Blob. I guess that would imply having a File object that is not necessarily backed by an on-disk representation. Obviously, there was nothing promising that before. Your proposal sounds reasonable to me. -Darin -- Anne van Kesteren http://annevankesteren.nl/
Re: FormData with sliced Blob
On Tue, 23 Mar 2010 01:26:32 +0100, 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. Which GUID? Is that in the File API specification? -- Anne van Kesteren http://annevankesteren.nl/
Re: FormData with sliced Blob
I mean UUID. It is the UUID part in URN of the File API spec. The UA can choose any appropriate way to generate a unique string, like UUID. On Tue, Mar 23, 2010 at 9:30 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 23 Mar 2010 01:26:32 +0100, 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. Which GUID? Is that in the File API specification? -- Anne van Kesteren http://annevankesteren.nl/
Re: FormData with sliced Blob
Unless we want to treat the blob same as string, we might have to provider some sort of filename. Since without it, the server side might have problem to save it temporarily. On Tue, Mar 23, 2010 at 1:06 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 23 Mar 2010 02:24:52 +0100, Dmitry Titov dim...@google.com wrote: 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) We previously discussed this and then we decided that for Blob Content-Type simply would not be present. I don't see why that would be different for multipart/form-data. Not really sure what to do about filename. -- Anne van Kesteren http://annevankesteren.nl/
Re: FormData with sliced Blob
Why couldn't FormData.append(Blob) provide optional parameters to allow the caller to specify the name and type? -Darin On Tue, Mar 23, 2010 at 1:06 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 23 Mar 2010 02:24:52 +0100, Dmitry Titov dim...@google.com wrote: 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) We previously discussed this and then we decided that for Blob Content-Type simply would not be present. I don't see why that would be different for multipart/form-data. Not really sure what to do about filename. -- Anne van Kesteren http://annevankesteren.nl/
Re: FormData with sliced Blob
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
Re: FormData with sliced Blob
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
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 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
