Re: data URIs - filename and content-disposition

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

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

Best regards, Julian

Received on Friday, 26 February 2010 14:16:37 UTC