Re: File constructor

[Alfonso Martínez de Lizarrondo]

Almost a year ago there was a thread about this issue (ability to set the
filename for a Blob) :
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1342.html


2012/5/11 Bronislav Klučka 

> Hi,
> currently File object cannot be constructed, only Blob can.
> I'm currently implementing XHR blob upload, that blob can either be File
> (selected by user) or programatically created Blob.
> On server side :
> 1/ In case of File, I get file name as part of the file metadata (name,
> size, type, etc)
> 2/ In case of Blob, I cannot specify name and I have to send it as
> additional parameter and ignore name metadata
>
> sending multiple files/blobs at once can be a mess
>
> is there a reason, while File cannot be created? It is Blob with has name
> and lastModifyDate .
> http://dev.w3.org/2006/webapi/**FileAPI/#file
>
> Could there be File constructor, that would work as Blob constructor with
> 3rd parameter specifying the name of the file and lastModifiedDate set to
> creation date
>
> Brona Klucka
>
>
>

Enable compression of a blob to .zip file

[Alfonso Martínez de Lizarrondo]

Hi all

I've tried to search the Webapps and WHATWG mailing lists for previous
discussions about this request, but I haven't been able to find anything.

My request can be explained easily: when uploading files to the server,
many times the upload time can be improved greatly if the file is
compressed instead of sent as-is; in my case I've adjusted some systems
that requires the user to upload a data file so it can accept both the
original file (mdb, csv, .xls, ), or a compressed version in .zip

When the user remembers to compress the zip everything goes fine, but many
times people might not be aware of that option, and so I think that it
would be useful to have an option (whatever objects or proposal about
methods are just quick ideas to explain the concept) on a Blob object to
compress it to a .zip and so get a new Blob

So the flow would be
1. User picks his data file with 
2. JS starts a XHR upload to show a progress bar
3. JS checks that the file is uncompressed, so it creates a zipped blob:

var file = input.files[0];
var extension = file.name.match( /\.([^\.]+)\s*$/ )[ 1 ];
if (extension.toLowerCase() != 'zip') file = file.toZip( 'compressed.zip' );
formData.append( file );
etc...

4. And the rest of the upload goes as usual.
5. The server gets the file and uncompresses it (the server doesn't really
care if the file was compressed in js or because the user did it, but the
js code can add a flag in the xhr upload to signal that it was
autocompressed.

Instead of a method on a Blob, it could be a separate object similar to
Mozilla nsIZipWriter (https://developer.mozilla.org/en/nsIZipWriter), but
with some simplifications to avoid extra verbose code.
var zipWriter = new zipWriter( 'compressed.zip' );
// This way it could be possible to add several files into the zip
zipWriter.addEntryFile( file);
formData.append( zipWriter );
etc...

Of course, in the files should be always added at the root of the zip
without any info about the original path. The compression can (and probably
should) be done asynchronously.

Would it be possible to add this new feature to some spec?
Thanks.

Re: [XHR2] Blobs, names and FormData

[Alfonso Martínez de Lizarrondo]

Julian Reschke also wanted to specify the mime type
El 23/08/2011 09:53, "Anne van Kesteren"  escribió:
> On Tue, 23 Aug 2011 02:25:38 +0200, Jonas Sicking 
wrote:
>> Given that this seems to be the way people prefer to do it, I'm fine
>> with doing that for Gecko too. But we definitely would need to get
>> FormData.append changed so that it supports the use case.
>
> So the current line for Blob can be replaced with
>
> append(DOMString name, Blob value, optional DOMString filename);
>
> right?
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/

Re: [XHR2] Blobs, names and FormData

[Alfonso Martínez de Lizarrondo]

I thought that the browser could retrieve that info from the os based on the
proposed extension.
I just requested the part that I needed, if there's something else missing
then I guess that it should be possible to add it at the same time.
 El 30/06/2011 09:28, "Julian Reschke"  escribió:

Re: [XHR2] Blobs, names and FormData

[Alfonso Martínez de Lizarrondo]

2011/6/29 Anne van Kesteren 

> On Wed, 29 Jun 2011 18:21:39 +0200, Alfonso Martínez de Lizarrondo <
> aml...@gmail.com> wrote:
>
>> If a png screenshot (as provided by current Chrome in the paste event) is
>> sent to the server and saved as "blob.bin" or "blob.blob", I doubt that it
>> will be sent back to the client with the correct mime type and I don't know
>> why the browser should try to sniff those contents instead of providing a
>> correct hint while uploading the data to the server.
>>
>> I don't really know a realistic situation where a page can generate a Blob
>> and don't know what kind of contents it has. It can be some text, some html,
>> some picture, the new APIs will allow to create new types of contents that
>> previously were out of scope for javascript, but in any of those situations
>> the script will know what kind of data it's dealing with and what's the
>> commonly expected extension for that content. So sending it in "the
>> correct way" seems to me like a logical step, supporting the FormData is far
>> more
>> complex than just allowing to specify the filename so it would be a pity
>> to forget about this missing bit.
>>
>
> Are you suggesting the browser should perform sniffing and decide the
> extension based on that? What rules should it follow?
>
> http://tools.ietf.org/html/**draft-ietf-websec-mime-sniff<http://tools.ietf.org/html/draft-ietf-websec-mime-sniff>
>
> I'm not sure dragging all that complexity here is a good idea.
>
>
> No.

All I want is a way for the web page to state that when a Blob is used in a
FormData object it should be send to the server with a proposed filename. No
sniffing. No guessing. It's up to the script to suggest a correct filename
(if it wants), or use whatever is the default filename used by the browser
(Blob23g22g3024j23g209gj3g and the like, extensionless)

My first simple approach was:
formdata.append("elementName", blob, "picture.png");

Jonas has suggested instead
blobbuilder.getFile("picture.png")

I don't mind one way or another, or something else you think it's better.
I'm just requesting for a way to specify the filename (specifically the
extension is the important part) that will be sent to the server.



> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [XHR2] Blobs, names and FormData

[Alfonso Martínez de Lizarrondo]

2011/6/29 Anne van Kesteren 

> On Wed, 29 Jun 2011 16:43:13 +0200, Alfonso Martínez de Lizarrondo <
> aml...@gmail.com> wrote:
>
>> 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.
>>
>
> What is the extension for unknown arbitrary contents? Is it .bin? We could
> also name it "blob.blob" if that improves matters. It really does not matter
> much.
>
>
>
If a png screenshot (as provided by current Chrome in the paste event) is
sent to the server and saved as "blob.bin" or "blob.blob", I doubt that it
will be sent back to the client with the correct mime type and I don't know
why the browser should try to sniff those contents instead of providing a
correct hint while uploading the data to the server.

I don't really know a realistic situation where a page can generate a Blob
and don't know what kind of contents it has. It can be some text, some html,
some picture, the new APIs will allow to create new types of contents that
previously were out of scope for javascript, but in any of those situations
the script will know what kind of data it's dealing with and what's the
commonly expected extension for that content. So sending it in "the correct
way" seems to me like a logical step, supporting the FormData is far more
complex than just allowing to specify the filename so it would be a pity to
forget about this missing bit.


> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

Re: [XHR2] Blobs, names and FormData

[Alfonso Martínez de Lizarrondo]

2011/6/29 Jonas Sicking 

> On Wednesday, June 29, 2011, Alfonso Martínez de Lizarrondo
>  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.
>
> 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.
>
>
Yes, my current concern is the missing extension.

With regards to the way to make it work, I just proposed some quick ideas,
but I'm in no way attached to anything. Anyone of you know far better how
this relates to other parts and the best way that it can be used for other
situations, I'm just a developer that only plays with whatever is available
in shipping code and then bangs his head against the wall when the goal is
so close but there's a little missing piece :-)

Thanks.


> / Jonas
>
>
> >
> >
> > El 29/06/2011 05:02, "Jonas Sicking"  escribió:
> >> On Fri, Jun 17, 2011 at 9:24 AM, Jonas Sicking 
> wrote:
> >>> On Friday, June 17, 2011, Anne van Kesteren  wrote:
> >>>> On Wed, 20 Apr 2011 23:52:21 +0200, Jonas Sicking 
> 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
> >>
> >
> >
>

Re: [XHR2] Blobs, names and FormData

[Alfonso Martínez de Lizarrondo]

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"  escribió:
> On Fri, Jun 17, 2011 at 9:24 AM, Jonas Sicking  wrote:
>> On Friday, June 17, 2011, Anne van Kesteren  wrote:
>>> On Wed, 20 Apr 2011 23:52:21 +0200, Jonas Sicking 
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
>

Re: Proposal for sending multiple files via XMLHttpRequest.send()

[Alfonso Martínez de Lizarrondo]

> Since XMLHttpRequest spec has already added the overload for send(document),
> why not just adding more overload for file and array of items? IMHO, having
> similar send*** methods, like sendFile, together with overloads of send()
> might make the API more complicated.

If the browser doesn't provide any system to detect that it supports
this feature, then the only way to enable it is to do UA sniffing, and
I thought that everyone agreed that this is bad because when the code
is deployed it must be updated for each new browser that implements
this API.

I wrote about my point of view about this kind of features in
http://alfonsoml.blogspot.com/2009/08/upload-progress-for-firefox-35.html
As I said there, if other browser implements that API the code will
work automatically for them. It's not a problem to add new code to
support a new API, but make it work based on UA it isn't nice.

Re: Proposal for sending multiple files via XMLHttpRequest.send()

[Alfonso Martínez de Lizarrondo]

2009/9/10 Jian Li :
> There has already been a discussion on extending XMLHttpRequest.send() to
> take a File object. Could we also consider enhancing it further to support
> sending multiple files, like a FileList from the drag and drop.
> We could make XMLHttpRequest.send() take a FileList object and let the
> browser add multipart boundary separators automatically..
> Or, the other simpler way, thanks to Darin's suggestion, is to
> extend XMLHttpRequest.send() to take an array of items. Each of item could
> be either a string or a file reference strictly. The web application is
> responsible to generate the multipart enevelop like the following:
>     var payload = new Array;
>     payload.push(header1);
>     payload.push(file1);
>     payload.push(footer1);
>     ...
>     xhr.send(payload);
> How do you guys think about these approaches?
> Thanks,
> Jian
>

How is supposed the web application to detect that the browser
supports this feature?

And between the two approaches, the first one is simpler, but the
second one allows to send the files one each time and add other form
data in the request.

Re: proposal to expose word breaker through JavaScript

[Alfonso Martínez de Lizarrondo]

This is the Microsoft version: range.expand
http://msdn.microsoft.com/en-us/library/ms536421%28VS.85%29.aspx


2009/7/29 Anne van Kesteren :
> On Wed, 29 Jul 2009 02:42:04 +0200, Xiaomei Ji  wrote:
>> We are proposing the following API to expose word breaker through
>> JavaScript.
>> document.extendRange(range, "word")
>>  It extends the passed-in range to a range in word boundary.
>>  If the passed-in range is an empty range, in which the beginning and
>> ending
>> are the same, the empty range will be extended to a one-word range covers
>> the beginning/ending of passed-in range. In the case where the
>> beginning/ending of passed-in range is at a word boundary, the logically
>> next word will be selected.
>>
>> If the beginning and ending of the passed-in range are not the same, the
>> range is extended to word boundary on both sides. Which means the
>> beginning will be extended to the word boundary on its logically left side 
>> if it is
>> not at a word boundary, and ending will be extended to the word boundary
>> on its logically right side if it is not at a word boundary.
>>
>> Please let us know if there is any issues, concerns with the proposal.
>
> Initially I did not quite understand what this API was proposing, but after 
> reading it a few times it seems to mimic the behavior of what typically 
> happens when you double-click a "word".
>
> I'm still not quite sure whether I understand the API though. Is "word" a 
> keyword on how the range is to be extended or is it an example? Also, 
> wouldn't it be better to put the method on Range rather than Document?
>
> And finally, use cases would help as well as a definition of "word boundary" 
> and how this works/won't work in an international context.
>
> Cheers,
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>

Re: File Upload Status ?

[Alfonso Martínez de Lizarrondo]

Although the thread is almost a year old, I haven't found any replies
to these questions, so I'm sharing what I've found:

> I have a few questions and an idea.
>
> Does calling send( file ) generate the appropriate Content-Type
> request header with matching boundary?

No, it doesn't. I've filed
https://bugs.webkit.org/show_bug.cgi?id=26979 about it.

> How can this feature be detected?

I don't think that it can be detected. You must know that the visitor
is using the correct webkit version.

> Idea:
> How about passing a form to send? When passing a form to send, the
> correct headers are set from the form's enctype, generating the
> boundary, content-disposition and other stuff for multipart requests.

Yes, that's what I thought that day after sleeping. That would be
great, much better than the option of Firefox 3.5 to read the whole
file as a string and send that. The browser takes care of reading the
file and sending it as it is needed, like any current form without
extra memory requirements.

> The only problem is that it complicates send with much functionality.
> Responsibly adaptive and well designed web apps will want to creat
> feature tests and fallback strategies, but this will be awkward and
> difficult to do, given the current API. Why not create a separate
> method - sendForm.
>
> if(xhr.sendForm)
>   xhr.sendForm(form);
>
> Garrett

That's exactly the proposal that I wanted to present to the Web Apps,
if it's possible to reuse exactly the same server code, but provide an
UI at the browser then lots of people will gladly use it. Just think
that basically the code to degrade gracefully would be
if (xhr.sendForm)
   xhr.sendForm(form);
else
   form.send();

Regards