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

What about this?

Say you have this file:

"with spaces.txt"
---------
√
---------

and want that as data URI that's treated as an attachment with a filename  
hint of "with spaces.txt".

Well, you might want headers like this:

Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; filename="with spaces.txt"
Content-Language: en

So, how bout doing it like the following?:

data:text/plain;charset=utf-8;headers=Content-Disposition%3A%20attachment%3B%20filename%3D%22with%20spaces.txt%22%0D%0AContent-Language%3A%20en,%E2%88%9A

That way, 'text/plain;charset=utf-8' would be the full Content-Type header  
and the rest of the headers can be specified as \r\n-separated lines like  
in HTTP. It's tagged with "headers=" so it can be found in the string  
easily, and the value is percent-encoded so it doesn't interfere with  
existing UA handling of data URIs.

The restriction would be that the headers value can't contain a  
Content-Type header (since it's already implied. And, perhaps, it should  
be specified exactly what headers are allowed in the headers value.

It even works (as in, doesn't cause a problem) with ;base64 at the end  
like this (in Opera at least):

data:text/plain;charset=utf-8;headers=Content-Disposition%3A%20attachment%3B%20filename%3D%22with%20spaces.txt%22%0D%0AContent-Language%3A%20en;base64,4oiaDQo%3D

I guess that might mean that the headers value shouldn't allow a  
Content-Encoding header as that should be specified separately after the  
headers value like ;base64 or ;gzip.

Also, instead of 'headers=', it could be %0D%0A to signify the end of the  
content-type header and further be closer to how http does things and  
would look like this:

data:text/plain;charset=utf-8;%0D%0AContent-Disposition%3A%20attachment%3B%20filename%3D%22with%20spaces.txt%22%0D%0AContent-Language%3A%20en,%E2%88%9A

What other things use 'data:' beside browsers that I could test to see if  
they break?

Or, 'data-extended:' might open up more possibilities.

-- 
Michael

Received on Thursday, 25 February 2010 16:07:34 UTC