Re: data URIs - filename and content-disposition

On Fri, 26 Feb 2010 09:15:56 -0500, Julian Reschke <julian.reschke@gmx.de>  
wrote:

> On 26.02.2010 14:57, Michael A. Puls II wrote:
>> ...
>>> 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).
>
> +1
>
>>> 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.
>
> We'll need to define which characters need to be percent-escaped,  
> though. Obviously all non-URI characters, but also those needed to parse  
> the parameters, so minimally ";".

Well, encodeURIComponent basically percent-encodes anything not in  
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.!~*'()"

, which is great to me. That covers encoding ; too.

>> 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.
>
> Maybe just refer to  
> <http://greenbytes.de/tech/webdav/rfc2183.html#rfc.section.2.8>? This  
> makes unknown extension types equivalent to "attachment".

I'm happy either way :)

-- 
Michael

Received on Friday, 26 February 2010 14:34:27 UTC