W3C home > Mailing lists > Public > uri@w3.org > February 2010

Re: data URIs - filename and content-disposition

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Wed, 24 Feb 2010 05:58:17 -0500
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: uri@w3.org
Message-ID: <op.u8moresm1ejg13@sandra-svwliu01>
On Wed, 24 Feb 2010 05:34:55 -0500, Julian Reschke <julian.reschke@gmx.de>  

> On 24.02.2010 08:04, Michael A. Puls II wrote:
>> I have a web page that's meant to run locally via file:. It uses XHR to
>> load a vcard file. I then scan the file and convert it to a different
>> text file format.
>> I want to provide a save link for the new file format, so I decided to
>> use a data URI. But, I want clicking on the data URI link to show an
>> open/save dialog.
>> I was able to do this by using <a
>> href="data:application/octetstream;charset=utf-8,file_data"
>> target="_blank">Save</a>.
>> However, there are 2 problems.
>> 1. There doesn't seem to be a way to give a filename hint.
>> 2. I'd rather not use the octetstream mime type just to trigger a save
>> dialog.
>> With that said, I think it'd be awesome if you could do something like:
>> <a
>> href="data:text/plain;charset=utf-8;filename=tada.txt;content-disposition=attachment,file_data">Save</a>.
>> Setting aside the File API work, what about specifying those two in an
>> update to the data URI RFC? Any vendors against implementing support for
>> it?
> Sounds like a nice idea; a few thoughts:
> - Given the sad state of data URI parsing in UAs, it may be hard to  
> deploy this extension; did you make tests whether existing UAs properly  
> parse (== ignore) new parameters?

I tested a little in Safari, Opera, Firefox and IE. The extra params don't  
seem to bother Firefox, Safari and Opera. I can't get data URIs to work at  
all in IE atm, so...

However, I didn't test complex filename values and the different ways you  
can encode them. If I remember correctly, IE handles filename values  
differently than the RFC and other browsers.

So, I suspect that IE will probably give the most trouble. Although, I'm  
sure I could find bugs in the other browsers too.

But, I'm hopeful that it wouldn't be too hard for browsers to support.

> - An alternative would to define a way to include arbitrary headers; so  
> that Content-Disposition could be used as defined (but this may get  
> messy)
> - It would be nice to align this with the current IETF work on  
> rephrasing RFC 2231 and RFC 2183 for use in HTTP...


Received on Wednesday, 24 February 2010 10:58:45 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:53 UTC