W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [XHR2] Blobs, names and FormData

From: Alfonso Martínez de Lizarrondo <amla70@gmail.com>
Date: Wed, 29 Jun 2011 16:43:13 +0200
Message-ID: <BANLkTimw-uo8h_j8KwgpNm+BMogoTEmA6w@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Webapps WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>
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


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 Wednesday, 29 June 2011 14:43:42 GMT

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