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: Fri, 26 Feb 2010 08:57:43 -0500
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: uri@w3.org
Message-ID: <op.u8qmeel31ejg13@sandra-svwliu01>
On Fri, 26 Feb 2010 08:20:39 -0500, Julian Reschke <julian.reschke@gmx.de>  
wrote:

> On 25.02.2010 17:06, Michael A. Puls II wrote:
>> ...
>> 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):
>> ...
>
> The advantage of this is that it's flexible.
>
> The disadvantage is that it may be too flexible :-). For instance, you'd  
> either need to restrict the micro syntax for embedded headers, or  
> recipients will need to run this through a full-blown HTTP header parser  
> (which may be hard to do).

Yeh, I was thinking of that too. For browsers, percent-decoding it and  
running it through a full-blown http header parser probably wouldn't be a  
problem. For others though, it might. And, with the way the filename can  
be encoded, even if you were to split up the headers and their different  
parts properly, you'd have to write a decoder for the filename.

I'm also not sure about the performance concerns with using a full-blown  
http header parser every time a data URI is invoked (which could be a lot  
if you load a page full of data URIs-based img elements. But, that'd be  
the author's fault for including the extra, non-needed headers in that  
case).

> So I have a slight preference to keep things simple, and to focus on the  
> specific use case.

Well, I'm personally happy with just:

data:text/plain;charset=utf-8;content-disposition=attachment;filename=name,

(that could even be shortened to just disposition=attachment)

I just suggested the more flexible way as I figured that's what most  
people would want.

Now, if we do it just the simple way, how should the filename value be  
encoded? Just percent-encoded UTF-8? That'd be fine by me because I could  
just use encodeURIComponent() to produce the value.

For the disposition value, it'd be handled like this:

If the disposition value is present and is "inline" or "attachment", the  
browser tries to treat it as such. Else, do like browsers do now.

-- 
Michael
Received on Friday, 26 February 2010 13:58:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:14 UTC