Created attachment 251771 [details] Demonstration of the exploit I confirm that the observed phenomenon is in effect for the Internet zone as well. See the attached HTML page in action at http://jsnet.sourceforge.net/tmp/367231.html
What is this exploiting? This looks like mostly-proper use of the data: protocol to me, not a bug. There is a problem with your webpage that it uses plain/text instead of text/plain. So instead of displaying the data, we try to save it to disk.
Thanks for bringing this post to our attention. This is how the data: scheme is supposed to work, the only odd behavioral issue is that since it wasn't loaded from a particular path from which we could take a file name, and because it's not an HTML document where we could use the <title>, we pick a unique temporary name. This is not a security problem. Because it's confusing you could make the case for an enhancement request that we should prompt the user for a filename when we don't have one rather than pick something random.
I too am running into this issue. I want to forward an hCalendar microformat appointment from Firefox to PalmDesktop. I use: <a href="data:text/x-vcalendar,_escaped VEVENT comes here_"/> However, as reported previously, Firefox picks up not only a random file name. Beside the filename, there's another issue: Firefox does not add an extension to the filename (how could it when it does know what the user intends?). This leads to the appointment being ignored by PalmDesktop. Suggestion: add "name" or "filename" parameter to the data: URI scheme (as per older RFC1806 or former Content-Disposition header field). Example: <a href="data:text/x-vcalendar;filename='event.vcs',..."/>
Comment 5 seems like a good strategy to me. Short of that, and easier, is to attempt to infer an extension from the MIME type; possibly having a short hard-coded list, or, better, using the OS MIME-typing mechanism.
When saving a inline file (NOT image), Firefox (3.0.6/Win32) generates temporary file name with the correct extension (by mimetype), but it also appends the ".part" extension, so the saved file has confusing name "filename.ext.part" instead of expected "filename.ext". This shoud be also corrected.
Comment #6 is from 04.2007 and #7 - 02.2009. Is there any progress with that issue? I'm trying to use such a functionality when generating m3u file from a page. The strange thing is that if i save the generated with a random name file it is in format <random-name>.m3u.part, but if i choose to open it, instead of directly saving it, file name is in format <random-name>.m3u.part.m3u.
Not entirely sure where this should go, but data: URI support is Core... somewhere.
Until this gets fixed it is impossible to perform client side file processing and export. Chrome has added a download attribute to a tags that handles the naming of the file. http://html5-demos.appspot.com/static/a.download.html
> Chrome has added a download attribute to a tags that handles the naming of > the file. http://html5-demos.appspot.com/static/a.download.html See bug 676619
5 years old issue...
Changing the data: URL scheme to add a filename would imply non-complaince with RFC 2397. The only way to include the filename in the URI would be to hack the "mediatype" value by adding non-standard parameters. This may have an imapct on the browser interpretation of conten-length that would need to be assessed. The best solution I can find is to use the download attribute of <a> tag. This is being solved in bug 676619 and should be implemented in Firefox 20.
(In reply to Kris from comment #15) > Changing the data: URL scheme to add a filename would imply non-complaince > with RFC 2397. The only way to include the filename in the URI would be to > hack the "mediatype" value by adding non-standard parameters. Since the mediatype has an explicit provision for _custom_ attribute=value pairs (see the referenced RFC2045, page 12), using it for signaling a preferred filename wouldn't be a hack nor a non-compliance with the RFC. In the worst cast it could be considered a mere extension of the RFC. Also, IMHO, using the "download attribute of <a> tag" would be ugly for data programmatically generated by js code.