Re: [whatwg] Uploading directories of files
This thread (of which some especially salient points are included below) requested the addition of a feature or the codifying of a convention for uploading directory tree structures in input type=file. I think that including relative directory paths with uploads is a quite reasonable feature. However, I don't think we really yet have good experience with what the right conventions should be. I would recommend that browser vendors experiment with this feature and report back their findings, so that we can converge on a proven convention. On Thu, 10 Dec 2009, Ian Fette (�~B��~B��~C��~C~U�~B��~C~C�~C~F�~B�) wrote: Many sites allow you to upload multiple files, often images. HTML5 allows this via input type=file multiple. This works well when your files are all in one folder, but it may often be the case that files are spread across sub-folders, and in this case you have to do multiple transactions (or multiple input type=file multiple tags, which is just awkward) to upload your files. PROPOSAL: Allow a UA to recursively select and upload a directory of files. How the UA chooses to modify the file picker dialog is outside the scope of this spec, but for the sake of argument, assume that the UA lets you pick a folder and say upload all. Allow the UA to upload the files in the folder, with the subdirectories included in the filename with a directory separator. E.g. assume I have: C:\users\ian\a\b\1.jpg C:\users\ian\a\b\2.jpg C:\users\ian\a\c\3.jpg If the user chooses a, the UA should be allowed to send all three files with filenames: a/b/1.jpg a/b/2.jpg a/c/3.jpg as it would for the existing input type=file multiple implementation, with the addition of the directories and path separators (not full path, just the directory the user chose and sub-paths.) On Thu, 10 Dec 2009, Jonas Sicking wrote: I don't think there is anything in the spec preventing you from doing this right now. The fact that only files in the same folder can be selected is a limitation in the implementation, not a limitation in the spec. The spec does require that only the leaf name, without any paths, are submitted. Is that a problem? I guess I'd be ok with changing the spec to allow more of the path to be exposed. However that would mean that there is a mismatch between what name is submitted and what name you'd get from input.files[n].name. On Thu, 10 Dec 2009, Ian Fette (�~B��~B��~C��~C~U�~B��~C~C�~C~F�~B�) wrote: I think that the notion of allowing more of the path to be exposed and reconciling that with .name is where the problem lies, and would like to figure out if we could resolve that. I think that there is a case to be made for including the paths -- e.g. if I'm uploading photos to flickr, picasa, or facebook, I may have already organized them locally, there's no reason that I shouldn't be able to maintain that structure when I upload to the web application. The question is then how that gets reconciled with input.files[n].name -- I would think it preferable if .name also were allowed to contain that extra information -- currently we say The name of the file. There are numerous file name variations on different systems; this is merely the name of the file, without path information.. I guess I would propose that be changed to The name of the file. There are numerous file name variations on different systems; this is merely the name of the file. If the user agent allows for files from multiple directories to be selected and included in a single FileList, path information may be included to distinguish between the files, provided that such path information SHOULD NOT include information about any path components that are common to all of the Files in the FileList. On Thu, 10 Dec 2009, Jonas Sicking wrote: If we're going to expose a full or partial path, then I think we should do that separately from the .name property. I'd rather keep the .name strictly be the leaf name. On Fri, 11 Dec 2009, Markus Ernst wrote: If I understand you correctly, this would lead to differences in file names based on the UA, and even based on the folder that the user actually chose to upload. See your example: C:\users\ian\a\b\1.jpg C:\users\ian\a\b\2.jpg C:\users\ian\a\c\3.jpg 1. The user anually selects files 1.jpg and 2.jpg in directory b. The resulting filename of the first file is 1.jpg. 2. Tho other day the user does an update, but this time selects directory b and does upload all. Resulting filename: b/1.jpg. 3. For the next update the user wants to easily upload all 3 files, which results in: a/b/1.jpg. 4. Then the same action is done from another computer with a different UA, the file might again be named 1.jpg. On Fri, 11 Dec 2009, Jeremy Orlow wrote: Personally, I don't think the case Markus pointed out is at all a show stopper. In the case of images, the server could easily
Re: [whatwg] Uploading directories of files
On Friday 2009-12-11 02:17 -0800, Jeremy Orlow wrote: But regardless.I don't think you could argue that having _some_ path information is worse than _none_, right? Many of those who commented in https://bugzilla.mozilla.org/show_bug.cgi?id=143220 and its duplicates would disagree. Users may not expect the act of uploading a file to give the Web site details of their file system structure. There also seems to be some concern that those details may provide information useful to an attacker. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Uploading directories of files
Rereading comments 1 - 24 of https://bugzilla.mozilla.org/show_bug.cgi?id=143220 as cited below, reveals to me that I was not the only one in the past 7 years to encounter the many use cases (involving client-side access to local images). I was quite disappointed when it finally became disabled in all browsers. (circa 2006 in IE, I think). Thanks to David B. for pointing out the history of some of the discussion within Mozilla and to Jonas for pointing out the demos of Firefox 3.6 using the new file API from http://www.w3.org/TR/FileAPI/ . It looks like this will address my use cases (including a client-side animation studio and client-side image manipulation). Between the various proposed methods and canvas, it looks like one will be able to do lots of fancy stuff. One question I have about the FileAPI: should I address it here or contact the group responsible at public-weba...@w3.org ? That is while I see a method for grabbing blobs consecutive bytes from the image file, what might also be quite handy would be the old-fashioned Bit-blit sort of stuff. Specifically, it would be nice to deal with an arbitrary sub-rectangle of an image on the screen. Currently, I believe (correct me if I'm wrong), to use a clip region in either SVG or HTML of an image displayed in the browser (from a local or remote source), one has to essentially create a new version of the image (see either http://srufaculty.sru.edu/david.dailey/javascript/weave/weaver.htm or http://srufaculty.sru.edu/david.dailey/svg/clips2.svg ) to overlay clips. This is expensive in RAM and performance as the data in http://www.svgopen.org/2007/papers/BrowserPerformanceMeasures/index.html would indicate. By being able to sample, for example a 20 pixel by 20 pixel sub-image of a rectangle as its own bitmap, would be considerably more efficient than the ways I have been doing this sort of thing. But if I understand the BLOB, it would be consecutive bytes from the actual file itself, as compressed in GIF, JPEG or PNG (or SVG???) format?? That would be useful for certain kinds of image analysis, but for higher level image manipulation, having to deal with all those bytes in JavaScript would be much slower it seems than something implemented close to the onscreen (or offscreen) drawing. I like the direction this is going though! cheers David - Original Message - From: L. David Baron dba...@dbaron.org To: Jeremy Orlow jor...@chromium.org Cc: Markus Ernst derer...@gmx.ch; whatwg wha...@whatwg.org Sent: Sunday, December 13, 2009 3:01 AM Subject: Re: [whatwg] Uploading directories of files On Friday 2009-12-11 02:17 -0800, Jeremy Orlow wrote: But regardless.I don't think you could argue that having _some_ path information is worse than _none_, right? Many of those who commented in https://bugzilla.mozilla.org/show_bug.cgi?id=143220 and its duplicates would disagree. Users may not expect the act of uploading a file to give the Web site details of their file system structure. There also seems to be some concern that those details may provide information useful to an attacker. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Uploading directories of files
2009/12/11 Anne van Kesteren ann...@opera.com On Fri, 11 Dec 2009 15:24:37 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: Ok, I sense resistance to putting it in .name. What about .path, undefined in most cases except where there is an upload including files from multiple directories, in which case .path contains the path less any path components common to all 3 (sorry, it's early morning and I can't write well before having coffee). e.g. input.files[0].name=1.jpg input.files[0].path=a/b input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c (Need to figure out the exact wording, as a is common to all 3 but if you're uploading the entire directory a, it may make sense to include that in the path -- but I don't feel quite as strongly about that -- subfolders are certainly more important IMO.) Note that extensions to File should be discussed on public-weba...@w3.org. At least, that's where they have been so far. Anne -- happy to move the File related discussion to public-weba...@. For the sake of wrapping up this thread though, are there there any changes that would need to be made to the HTML spec to allow this behavior (including limited path information in the name that gets sent when the form is posted?) I can't seem to find the actual part of the spec that defines or restricts what characters are valid in context. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Uploading directories of files
2009/12/13 Ian Fette (イアンフェッティ) ife...@google.com: 2009/12/11 Anne van Kesteren ann...@opera.com On Fri, 11 Dec 2009 15:24:37 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: Ok, I sense resistance to putting it in .name. What about .path, undefined in most cases except where there is an upload including files from multiple directories, in which case .path contains the path less any path components common to all 3 (sorry, it's early morning and I can't write well before having coffee). e.g. input.files[0].name=1.jpg input.files[0].path=a/b input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c (Need to figure out the exact wording, as a is common to all 3 but if you're uploading the entire directory a, it may make sense to include that in the path -- but I don't feel quite as strongly about that -- subfolders are certainly more important IMO.) Note that extensions to File should be discussed on public-weba...@w3.org. At least, that's where they have been so far. Anne -- happy to move the File related discussion to public-weba...@. For the sake of wrapping up this thread though, are there there any changes that would need to be made to the HTML spec to allow this behavior (including limited path information in the name that gets sent when the form is posted?) The only change needed as far as I can tell is to say that *if* the File objects contain any path information, that that path information is included as part of the filename when the data is submitted. The other change is to convince Arun that the File API spec should add a .path property that contains (possibly partial) path information when that is safe. Or some such. However I would probably in general recommend that you follow the steps outlined in the FAQ for new features: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F There the next step would be to just add a implementation to chrome. / Jonas
Re: [whatwg] Uploading directories of files
Ian Fette (イアンフェッティ) schrieb: I would think it preferable if .name also were allowed to contain that extra information -- currently we say The name of the file. There are numerous file name variations on different systems; this is merely the name of the file, without path information. [1]. I guess I would propose that be changed to The name of the file. There are numerous file name variations on different systems; this is merely the name of the file. If the user agent allows for files from multiple directories to be selected and included in a single FileList, path information may be included to distinguish between the files, provided that such path information SHOULD NOT include information about any path components that are common to all of the Files in the FileList. If I understand you correctly, this would lead to differences in file names based on the UA, and even based on the folder that the user actually chose to upload. See your example: C:\users\ian\a\b\1.jpg C:\users\ian\a\b\2.jpg C:\users\ian\a\c\3.jpg 1. The user anually selects files 1.jpg and 2.jpg in directory b. The resulting filename of the first file is 1.jpg. 2. Tho other day the user does an update, but this time selects directory b and does upload all. Resulting filename: b/1.jpg. 3. For the next update the user wants to easily upload all 3 files, which results in: a/b/1.jpg. 4. Then the same action is done from another computer with a different UA, the file might again be named 1.jpg. I have no idea how to handle such inconsistent behaviour on the server side (except adding extra code to flatten all uploaded directory structures before handling). I assume that HTTP upload should be kept simple, and more complex upload tasks should be handled with specialized applications, such as RadUpload[1]. [1] http://www.radinks.com
Re: [whatwg] Uploading directories of files
On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst derer...@gmx.ch wrote: I have no idea how to handle such inconsistent behaviour on the server side (except adding extra code to flatten all uploaded directory structures before handling). I assume that HTTP upload should be kept simple, and more complex upload tasks should be handled with specialized applications, such as RadUpload[1]. [1] http://www.radinks.com I don't think we want to rely on the availability of Java on the end user's platform (or the availability of any other plug-in for that matter). -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Uploading directories of files
Anne van Kesteren schrieb: On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst derer...@gmx.ch wrote: I have no idea how to handle such inconsistent behaviour on the server side (except adding extra code to flatten all uploaded directory structures before handling). I assume that HTTP upload should be kept simple, and more complex upload tasks should be handled with specialized applications, such as RadUpload[1]. [1] http://www.radinks.com I don't think we want to rely on the availability of Java on the end user's platform (or the availability of any other plug-in for that matter). I did not mean including it into HTML5 or an UA. Just leaving specialized upload tasks out of the standard, assuming that developers will work with applications that they think are useful for their tasks (and that rely on technologies they believe are avaliable at their target audience).
Re: [whatwg] Uploading directories of files
On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren ann...@opera.comwrote: On Fri, 11 Dec 2009 09:33:06 +0100, Markus Ernst derer...@gmx.ch wrote: Anne van Kesteren schrieb: On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst derer...@gmx.ch wrote: I have no idea how to handle such inconsistent behaviour on the server side (except adding extra code to flatten all uploaded directory structures before handling). I assume that HTTP upload should be kept simple, and more complex upload tasks should be handled with specialized applications, such as RadUpload[1]. [1] http://www.radinks.com I don't think we want to rely on the availability of Java on the end user's platform (or the availability of any other plug-in for that matter). I did not mean including it into HTML5 or an UA. Just leaving specialized upload tasks out of the standard, assuming that developers will work with applications that they think are useful for their tasks (and that rely on technologies they believe are avaliable at their target audience). And I mean that if it is important to application developers we should make it available as a feature and not endorse some plug-in dependency. I (and I think most of us) strongly agree. That's the whole point of standardization. :-) Personally, I don't think the case Markus pointed out is at all a show stopper. In the case of images, the server could easily recognize and reconcile duplicates (by hashing them and looking for duplicate hashes or something). If the image has been tweaked some in the mean time, the EXIF data can help. And so onthis seems like the type of thing clever developers can work around. But regardless.I don't think you could argue that having _some_ path information is worse than _none_, right? I also agree with Jonas that if some path information is added, it might be better to create a new property (other than .name) for it. And, with or without that extra property, I think what Ian's suggesting would be useful to users. J
Re: [whatwg] Uploading directories of files
Anne van Kesteren schrieb: On Fri, 11 Dec 2009 09:33:06 +0100, Markus Ernst derer...@gmx.ch wrote: Anne van Kesteren schrieb: On Fri, 11 Dec 2009 09:13:52 +0100, Markus Ernst derer...@gmx.ch wrote: I have no idea how to handle such inconsistent behaviour on the server side (except adding extra code to flatten all uploaded directory structures before handling). I assume that HTTP upload should be kept simple, and more complex upload tasks should be handled with specialized applications, such as RadUpload[1]. [1] http://www.radinks.com I don't think we want to rely on the availability of Java on the end user's platform (or the availability of any other plug-in for that matter). I did not mean including it into HTML5 or an UA. Just leaving specialized upload tasks out of the standard, assuming that developers will work with applications that they think are useful for their tasks (and that rely on technologies they believe are avaliable at their target audience). And I mean that if it is important to application developers we should make it available as a feature and not endorse some plug-in dependency. Ok. Jonas Sicking schrieb: If we're going to expose a full or partial path, then I think we should do that separately from the .name property. I'd rather keep the .name strictly be the leaf name. I support this point. I assume that changing the name property would break backwards compatibility, as server-side applications (at least the ones I wrote) rely on the current behaviour. There is an other aspect in Ians proposal - avoiding file name conflicts, when e.g. /a/1.jpg and /b/1.jpg are uploaded. This can be handled by the UA, for example by displaying an error message, allowing to rename the conflicting files before upload.
Re: [whatwg] Uploading directories of files
Jeremy Orlow schrieb: On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren ann...@opera.com And I mean that if it is important to application developers we should make it available as a feature and not endorse some plug-in dependency. I (and I think most of us) strongly agree. That's the whole point of standardization. :-) Personally, I don't think the case Markus pointed out is at all a show stopper. In the case of images, the server could easily recognize and reconcile duplicates (by hashing them and looking for duplicate hashes or something). If the image has been tweaked some in the mean time, the EXIF data can help. And so onthis seems like the type of thing clever developers can work around. But regardless.I don't think you could argue that having _some_ path information is worse than _none_, right? I also agree with Jonas that if some path information is added, it might be better to create a new property (other than .name) for it. And, with or without that extra property, I think what Ian's suggesting would be useful to users. Yes I see Anne's and your points. Anyway I don't see yet how to get _useful_ path information, as the same file can be posted as /a/b/1.jpg, and at the next occasion as 1.jpg or /b/1.jpg, just based on where in the upload dialog you did make the start point. Relying on information contained in the uploaded file does not seem to make sense to me, as you might want to upload a new file with the same name in order to replace the old one.
Re: [whatwg] Uploading directories of files
On Fri, Dec 11, 2009 at 2:30 AM, Markus Ernst derer...@gmx.ch wrote: Jeremy Orlow schrieb: On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren ann...@opera.com And I mean that if it is important to application developers we should make it available as a feature and not endorse some plug-in dependency. I (and I think most of us) strongly agree. That's the whole point of standardization. :-) Personally, I don't think the case Markus pointed out is at all a show stopper. In the case of images, the server could easily recognize and reconcile duplicates (by hashing them and looking for duplicate hashes or something). If the image has been tweaked some in the mean time, the EXIF data can help. And so onthis seems like the type of thing clever developers can work around. But regardless.I don't think you could argue that having _some_ path information is worse than _none_, right? I also agree with Jonas that if some path information is added, it might be better to create a new property (other than .name) for it. And, with or without that extra property, I think what Ian's suggesting would be useful to users. Yes I see Anne's and your points. Anyway I don't see yet how to get _useful_ path information, as the same file can be posted as /a/b/1.jpg, and at the next occasion as 1.jpg or /b/1.jpg, just based on where in the upload dialog you did make the start point. Relying on information contained in the uploaded file does not seem to make sense to me, as you might want to upload a new file with the same name in order to replace the old one. The information in the path could be seen as a hint that may or may not be provided. I feel like it'd be difficult security wise to guarantee that the hint will be there and/or consistent from upload to upload. But, once again, some hint is better than none, right? If you as a web developer don't think it's useful, you can ignore it, right?
Re: [whatwg] Uploading directories of files
Ok, I sense resistance to putting it in .name. What about .path, undefined in most cases except where there is an upload including files from multiple directories, in which case .path contains the path less any path components common to all 3 (sorry, it's early morning and I can't write well before having coffee). e.g. input.files[0].name=1.jpg input.files[0].path=a/b input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c (Need to figure out the exact wording, as a is common to all 3 but if you're uploading the entire directory a, it may make sense to include that in the path -- but I don't feel quite as strongly about that -- subfolders are certainly more important IMO.) 2009/12/11 Jeremy Orlow jor...@chromium.org On Fri, Dec 11, 2009 at 2:30 AM, Markus Ernst derer...@gmx.ch wrote: Jeremy Orlow schrieb: On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren ann...@opera.com And I mean that if it is important to application developers we should make it available as a feature and not endorse some plug-in dependency. I (and I think most of us) strongly agree. That's the whole point of standardization. :-) Personally, I don't think the case Markus pointed out is at all a show stopper. In the case of images, the server could easily recognize and reconcile duplicates (by hashing them and looking for duplicate hashes or something). If the image has been tweaked some in the mean time, the EXIF data can help. And so onthis seems like the type of thing clever developers can work around. But regardless.I don't think you could argue that having _some_ path information is worse than _none_, right? I also agree with Jonas that if some path information is added, it might be better to create a new property (other than .name) for it. And, with or without that extra property, I think what Ian's suggesting would be useful to users. Yes I see Anne's and your points. Anyway I don't see yet how to get _useful_ path information, as the same file can be posted as /a/b/1.jpg, and at the next occasion as 1.jpg or /b/1.jpg, just based on where in the upload dialog you did make the start point. Relying on information contained in the uploaded file does not seem to make sense to me, as you might want to upload a new file with the same name in order to replace the old one. The information in the path could be seen as a hint that may or may not be provided. I feel like it'd be difficult security wise to guarantee that the hint will be there and/or consistent from upload to upload. But, once again, some hint is better than none, right? If you as a web developer don't think it's useful, you can ignore it, right?
Re: [whatwg] Uploading directories of files
On Fri, 11 Dec 2009 15:24:37 +0100, Ian Fette (イアンフェッティ) ife...@google.com wrote: Ok, I sense resistance to putting it in .name. What about .path, undefined in most cases except where there is an upload including files from multiple directories, in which case .path contains the path less any path components common to all 3 (sorry, it's early morning and I can't write well before having coffee). e.g. input.files[0].name=1.jpg input.files[0].path=a/b input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c (Need to figure out the exact wording, as a is common to all 3 but if you're uploading the entire directory a, it may make sense to include that in the path -- but I don't feel quite as strongly about that -- subfolders are certainly more important IMO.) Note that extensions to File should be discussed on public-weba...@w3.org. At least, that's where they have been so far. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Uploading directories of files
Hi Ian, thanks for suggesting recursive directory selection! This comes almost a bit surprising to me, since Gears decided to deny this feature ( http://code.google.com/p/gears/wiki/FileSystemAPI). One of the reasons for the denial still applies: how can the user be sure what he is uploading? If the file chooser silently accesses files from subdirectories, the user must browse these first to avoid uploading of e.g. confidential data. So my suggestion is that the UA must provide a list of all uploaded files within a confirmation dialog before these files get uploaded. Franz 2009/12/11 Ian Fette (イアンフェッティ) ife...@google.com USE CASE: Many sites allow you to upload multiple files, often images. HTML5 allows this via input type=file multiple. This works well when your files are all in one folder, but it may often be the case that files are spread across sub-folders, and in this case you have to do multiple transactions (or multiple input type=file multiple tags, which is just awkward) to upload your files. PROPOSAL: Allow a UA to recursively select and upload a directory of files. How the UA chooses to modify the file picker dialog is outside the scope of this spec, but for the sake of argument, assume that the UA lets you pick a folder and say upload all. Allow the UA to upload the files in the folder, with the subdirectories included in the filename with a directory separator. E.g. assume I have: C:\users\ian\a\b\1.jpg C:\users\ian\a\b\2.jpg C:\users\ian\a\c\3.jpg If the user chooses a, the UA should be allowed to send all three files with filenames: a/b/1.jpg a/b/2.jpg a/c/3.jpg as it would for the existing input type=file multiple implementation, with the addition of the directories and path separators (not full path, just the directory the user chose and sub-paths.) Thoughts?
Re: [whatwg] Uploading directories of files
2009/12/11 Ian Fette (イアンフェッティ) ife...@google.com Ok, I sense resistance to putting it in .name. What about .path, undefined in most cases except where there is an upload including files from multiple directories, in which case .path contains the path less any path components common to all 3 (sorry, it's early morning and I can't write well before having coffee). e.g. input.files[0].name=1.jpg input.files[0].path=a/b input.files[1].name=2.jpg input.files[1].path=a/b input.files[2].name=3.jpg input.files[2].path=a/c (Need to figure out the exact wording, as a is common to all 3 but if you're uploading the entire directory a, it may make sense to include that in the path -- but I don't feel quite as strongly about that -- subfolders are certainly more important IMO.) What happens if the user then adds a single file from a different directory? Or if the user adds a second directory? Would the input element just disallow that or would all the paths be updated? Also, should the paths use the OS path separator or always be /? The latter seems preferable to me. Less OS specific code in the web platform. Ojan 2009/12/11 Jeremy Orlow jor...@chromium.org On Fri, Dec 11, 2009 at 2:30 AM, Markus Ernst derer...@gmx.ch wrote: Jeremy Orlow schrieb: On Fri, Dec 11, 2009 at 12:47 AM, Anne van Kesteren ann...@opera.com And I mean that if it is important to application developers we should make it available as a feature and not endorse some plug-in dependency. I (and I think most of us) strongly agree. That's the whole point of standardization. :-) Personally, I don't think the case Markus pointed out is at all a show stopper. In the case of images, the server could easily recognize and reconcile duplicates (by hashing them and looking for duplicate hashes or something). If the image has been tweaked some in the mean time, the EXIF data can help. And so onthis seems like the type of thing clever developers can work around. But regardless.I don't think you could argue that having _some_ path information is worse than _none_, right? I also agree with Jonas that if some path information is added, it might be better to create a new property (other than .name) for it. And, with or without that extra property, I think what Ian's suggesting would be useful to users. Yes I see Anne's and your points. Anyway I don't see yet how to get _useful_ path information, as the same file can be posted as /a/b/1.jpg, and at the next occasion as 1.jpg or /b/1.jpg, just based on where in the upload dialog you did make the start point. Relying on information contained in the uploaded file does not seem to make sense to me, as you might want to upload a new file with the same name in order to replace the old one. The information in the path could be seen as a hint that may or may not be provided. I feel like it'd be difficult security wise to guarantee that the hint will be there and/or consistent from upload to upload. But, once again, some hint is better than none, right? If you as a web developer don't think it's useful, you can ignore it, right?
Re: [whatwg] Uploading directories of files
2009/12/11 ddailey ddai...@zoominternet.net: Circa 1999 I built a little thingy: a client-side animation studio. It allowed users to point to an image file in local file space. Then I would preload the file, parse the path name and go looking for images with consecutively numbered filenames in the same directory by attempting a preload and checking the status of that -- hence allowing me to upload to the local machine a series. Once the sequences had been identified and loaded into the client-side app, the user then rearranged the sequence via GUI to create the perfect animation which was then bundled as the source of a new web page, complete with javascript and timing variables. It allowed the GUI calibration of all such parameters. It was pretty cool (and intensely useful for my students), but I realized as I was building it that being able to troll through a user's filenames was a bit of a security risk, since I could have shipped the files somewhere without the user's permission. I even recall asking some browser gurus about it, but they seemed largely unconcerned at the time. The miniapp worked in Netscape and IE (with a little tweaking). I'm fairly certain that any of the major browser vendors would be quite horrified if this worked today. I.e. if the page could just grab arbitrary files from the users file system. Occasionally people store private data there ;) However I don't think it's ever been the case that you could actually grab image data and send it the way you're describing. While it might have been that you could *display* images from arbitrary locations on the users file system, I'd imagine you couldn't actually grab the image data. Some years later it stopped working everywhere, and I discovered to my horror that the nasty standards folks had disabled client-side image processing altogether, requiring instead that users send all their images to my server for them to be able to even see their own files in the browser -- ahh progress! And all in the name of privacy! How charming. I really do think that client-side image processing is a useful thing: hence folks development of VML, SVG, Silverlight and Canvas. Allowing us to access our pictures in a browser app does make sense if there is some way to enable it. The good news is that this is working again! You should be able to write the same application using modern standards. The only difference is that users will have to attach all the relevant files, rather than just the first one (this works around the security problem you mention above). However if the files live in the same directory, this can be accomplished with just opening the filepicker once. Here's a couple of demos: http://hacks.mozilla.org/2009/12/firefox-36-fileapi-demo-reading-exif-data-from-a-local-jpeg-file/ http://hacks.mozilla.org/2009/12/multiple-file-input-in-firefox-3-6/ / Jonas
Re: [whatwg] Uploading directories of files
on Friday, December 11, 2009 6:11 PM Jonas Sicking wrote: I'm fairly certain that any of the major browser vendors would be quite horrified if this worked today. I.e. if the page could just grab arbitrary files from the users file system. Occasionally people store private data there ;) However I don't think it's ever been the case that you could actually grab image data and send it the way you're describing. While it might have been that you could *display* images from arbitrary locations on the users file system, I'd imagine you couldn't actually grab the image data. Thanks for your reply Jonas. Yes, there was no actual grabbing of pixel data, sorry if I made you think that, and indeed, I would agree that modern browser vendors would be horrified. It was rather astonishing to me, but as I say, my app was working in both Netscape and IE for more than a few years. But, yes it only enabled local display of images from the users file system and I never tried uploading any of the not-specifically-sanctioned images to a server; that was not the purpose of the app. I will be anxious to try out some of the demos you recommend, as I have a dozen or so little mini apps, the functionality of which has been broken for some time, that do client side manipulation of images, for example, this pretty cool one from 2002, which I have recently been trying to modernize. It weaves two pictures (in past, they could be user-selected) together according to a user-chosen weave pattern. I look forward to being able to do this again without having to make round trips to the server. If interested, you will note that some crazy histrionics had to be performed to get the thing working in Netscape which had different pathnames for the local filespace revealed than did IE. cheers David
Re: [whatwg] Uploading directories of files
2009/12/10 Ian Fette (イアンフェッティ) ife...@google.com: USE CASE: Many sites allow you to upload multiple files, often images. HTML5 allows this via input type=file multiple. This works well when your files are all in one folder, but it may often be the case that files are spread across sub-folders, and in this case you have to do multiple transactions (or multiple input type=file multiple tags, which is just awkward) to upload your files. PROPOSAL: Allow a UA to recursively select and upload a directory of files. How the UA chooses to modify the file picker dialog is outside the scope of this spec, but for the sake of argument, assume that the UA lets you pick a folder and say upload all. Allow the UA to upload the files in the folder, with the subdirectories included in the filename with a directory separator. E.g. assume I have: C:\users\ian\a\b\1.jpg C:\users\ian\a\b\2.jpg C:\users\ian\a\c\3.jpg If the user chooses a, the UA should be allowed to send all three files with filenames: a/b/1.jpg a/b/2.jpg a/c/3.jpg as it would for the existing input type=file multiple implementation, with the addition of the directories and path separators (not full path, just the directory the user chose and sub-paths.) Thoughts? I don't think there is anything in the spec preventing you from doing this right now. The fact that only files in the same folder can be selected is a limitation in the implementation, not a limitation in the spec. The spec does require that only the leaf name, without any paths, are submitted. Is that a problem? I guess I'd be ok with changing the spec to allow more of the path to be exposed. However that would mean that there is a mismatch between what name is submitted and what name you'd get from input.files[n].name. / Jonas
Re: [whatwg] Uploading directories of files
2009/12/10 Jonas Sicking jo...@sicking.cc 2009/12/10 Ian Fette (イアンフェッティ) ife...@google.com: USE CASE: Many sites allow you to upload multiple files, often images. HTML5 allows this via input type=file multiple. This works well when your files are all in one folder, but it may often be the case that files are spread across sub-folders, and in this case you have to do multiple transactions (or multiple input type=file multiple tags, which is just awkward) to upload your files. PROPOSAL: Allow a UA to recursively select and upload a directory of files. How the UA chooses to modify the file picker dialog is outside the scope of this spec, but for the sake of argument, assume that the UA lets you pick a folder and say upload all. Allow the UA to upload the files in the folder, with the subdirectories included in the filename with a directory separator. E.g. assume I have: C:\users\ian\a\b\1.jpg C:\users\ian\a\b\2.jpg C:\users\ian\a\c\3.jpg If the user chooses a, the UA should be allowed to send all three files with filenames: a/b/1.jpg a/b/2.jpg a/c/3.jpg as it would for the existing input type=file multiple implementation, with the addition of the directories and path separators (not full path, just the directory the user chose and sub-paths.) Thoughts? I don't think there is anything in the spec preventing you from doing this right now. The fact that only files in the same folder can be selected is a limitation in the implementation, not a limitation in the spec. The spec does require that only the leaf name, without any paths, are submitted. Is that a problem? Perhaps not a show stopper, but I think it's sub-optimal. E.g. if I am using a client application, I can point it to my My Photos directory and it can infer some album structure from how I've organized my photos. It would be nice if a web photo app could do the same. I guess I'd be ok with changing the spec to allow more of the path to be exposed. However that would mean that there is a mismatch between what name is submitted and what name you'd get from input.files[n].name. I think that the notion of allowing more of the path to be exposed and reconciling that with .name is where the problem lies, and would like to figure out if we could resolve that. I think that there is a case to be made for including the paths -- e.g. if I'm uploading photos to flickr, picasa, or facebook, I may have already organized them locally, there's no reason that I shouldn't be able to maintain that structure when I upload to the web application. The question is then how that gets reconciled with input.files[n].name -- I would think it preferable if .name also were allowed to contain that extra information -- currently we say The name of the file. There are numerous file name variations on different systems; this is merely the name of the file, without path information. [1]. I guess I would propose that be changed to The name of the file. There are numerous file name variations on different systems; this is merely the name of the file. If the user agent allows for files from multiple directories to be selected and included in a single FileList, path information may be included to distinguish between the files, provided that such path information SHOULD NOT include information about any path components that are common to all of the Files in the FileList. Again, open to suggestions of how this could be accomplished in a better way. [1] http://www.w3.org/TR/FileAPI/#dfn-name / Jonas
Re: [whatwg] Uploading directories of files
2009/12/10 Ian Fette (イアンフェッティ) ife...@google.com: I guess I'd be ok with changing the spec to allow more of the path to be exposed. However that would mean that there is a mismatch between what name is submitted and what name you'd get from input.files[n].name. I think that the notion of allowing more of the path to be exposed and reconciling that with .name is where the problem lies, and would like to figure out if we could resolve that. I think that there is a case to be made for including the paths -- e.g. if I'm uploading photos to flickr, picasa, or facebook, I may have already organized them locally, there's no reason that I shouldn't be able to maintain that structure when I upload to the web application. The question is then how that gets reconciled with input.files[n].name -- I would think it preferable if .name also were allowed to contain that extra information -- currently we say The name of the file. There are numerous file name variations on different systems; this is merely the name of the file, without path information. [1]. I guess I would propose that be changed to The name of the file. There are numerous file name variations on different systems; this is merely the name of the file. If the user agent allows for files from multiple directories to be selected and included in a single FileList, path information may be included to distinguish between the files, provided that such path information SHOULD NOT include information about any path components that are common to all of the Files in the FileList. If we're going to expose a full or partial path, then I think we should do that separately from the .name property. I'd rather keep the .name strictly be the leaf name. / Jonas / Jonas
