W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [XHR2] Blobs, names and FormData

From: Kinuko Yasuda <kinuko@chromium.org>
Date: Tue, 12 Jul 2011 03:36:08 +0900
Message-ID: <CAMWgRNYqpsCkMcuSYAaBGxvSSAQR_ZCo0xCKdedQ5u645+Lwxg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>, Darin Fisher <darin@google.com>, Michael Nordman <michaeln@google.com>
Cc: Alfonso Martínez de Lizarrondo <amla70@gmail.com>, Eric Uhrhane <ericu@google.com>, Webapps WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>
On Thu, Jun 30, 2011 at 12:30 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wednesday, June 29, 2011, Alfonso Martínez de Lizarrondo
> <amla70@gmail.com> wrote:
> > I didn't notice this thread and I filed [1] in webkit due to this
> behavior.
> > Providing an automatic filename it's better than sending an empty one,
> but it fails to address interaction with existing systems (some might refuse
> the upload if it doesn't look like a correct file type, at the very least a
> proper extension). The usual "solution" suggested/used when people create
> samples or code using these features is to add extra headers to send the
> desired filename, but that means that the server code has to be updated to
> handle this behavior.
> > This lead to the problem that it's not possible to provide an enhanced
> client-side feature like uploading of pasted images in webkit because it
> needs also changes to the server, and the level of changes might be quite
> different as people might be using quite different backends.
> > If the FormData could be expanded so that when doing a
> formdata.append("elementName", blob); could allow a third parameter to
> specify the filename to use then this could greatly simplify using new
> features.
> > Another option would be to allow a "filename" property on Blobs, but I'm
> not sure if that's correct as I think that right now the only use of that
> property would be when used with FormData.
> >
> > https://bugs.webkit.org/show_bug.cgi?id=63388
>
> Ok, so if I understand the problem correctly, it is that some servers
> only accept files with certain extensions, which fail here since
> "blob" doesn't have any extension.
>
> I'll note that not having control of the rest of the filename is
> nothing new since that's traditionally always been "whatever the name
> is on the users file system".
>
> I'd prefer to solve this be adding a .getFile(in DOMString name)
> function on BlobBuilder.
>

Is this meant to return a File object, which has a new 'name' associated
to the object but may not have an actual file on the local filesystem?
Actually a blob could be a file, in that case do we end up having multiple
arbitrary filenames that may not be related to the backing file?
I'm afraid this might contradict to existing assumptions about File.

This API also reminded me of the discussion about Content-Disposition
for blobs.  We (ericu) once proposed an idea adding C-D attribute to Blob
[1]
but it did not get much support at the time, and one of the objections was
Content-Disposition is NOT metadata about the file/blob while Content-Type
is.  So here I might wonder where this 'name' parameter
of getFile falls into--
to me this looks like a content-disposition info especially if it does not
refer the actual file name.

(I'm still trying to catch up threads and sorry if I'm taking something
wrong)

[1] http://www.mail-archive.com/public-webapps@w3.org/msg08520.html


That way you can create a file, with whatever name you want, which
> wraps your blob or misnamed file, and which has a name of your
> choosing. When that file is submitted using FormData it'll use the
> name you've chosen.



> / Jonas
>
>
> >
> >
> > El 29/06/2011 05:02, "Jonas Sicking" <jonas@sicking.cc> escribió:
> >> On Fri, Jun 17, 2011 at 9:24 AM, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >>> On Friday, June 17, 2011, Anne van Kesteren <annevk@opera.com> wrote:
> >>>> On Wed, 20 Apr 2011 23:52:21 +0200, Jonas Sicking <jonas@sicking.cc>
> wrote:
> >>>>
> >>>> When a Blob is appended to a FormData, the XHR2 spec currently says
> >>>> that the filename used should be the empty string unless the Blob is
> >>>> also a File. If such a FormData is later submitted using
> >>>> XMLHttpRequest, this will result in a request that contains something
> >>>> similar to:
> >>>>
> >>>> Content-Disposition: form-data; name="myblob"; filename=""
> >>>>
> >>>> Unfortunately there appears to be some servers that are unable to deal
> >>>> with the filename parameter being empty. See details and examples in
> >>>> [1]. Chrome apparently already disregards the specification here and
> >>>> generates a seemingly random value for the filename parameter.
> >>>>
> >>>> Unless someone comes up with a reason otherwise, I suspect we need to
> >>>> change the spec here.
> >>>>
> >>>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=649150
> >>>>
> >>>>
> >>>> Just set it to "blob" maybe? Or "blob.bin" or some such?
> >>>
> >>> That works for me. I'm curious to know why webkit went with a more
> >>> complex name though.
> >>
> >> I've written a patch to make Firefox use "blob" as name. This is used
> >> both when the FormData contains a Blob, and when it contains a File
> >> with an empty name.
> >>
> >> In firefox you can currently get a file with an empty name using an
> >> experimental canvas.mozGetAsFile(name, type, ...) API, though this
> >> will eventually be changed to canvas.toBlob as has now been specified.
> >> But I suspect we'll end up with other APIs eventually which can end up
> >> producing files with empty names (I kind'a think that BlobBuilder
> >> should have a getFile(name) function for example).
> >>
> >> / Jonas
> >>
> >
> >
>
>
Received on Monday, 11 July 2011 18:36:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT