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 09:33:51 -0500
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: uri@w3.org
Message-ID: <op.u8qn2pfr1ejg13@sandra-svwliu01>
On Fri, 26 Feb 2010 09:15:56 -0500, Julian Reschke <julian.reschke@gmx.de>  

> 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  

, 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 :)

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

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:53 UTC