Re: data URIs - filename and content-disposition

On Wed, 24 Feb 2010 05:34:55 -0500, Julian Reschke <julian.reschke@gmx.de>  
wrote:

> 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...

Thanks

-- 
Michael

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