W3C home > Mailing lists > Public > uri@w3.org > February 2010

Re: data URIs - filename and content-disposition

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 26 Feb 2010 14:20:39 +0100
Message-ID: <4B87CAA7.2020009@gmx.de>
To: "Michael A. Puls II" <shadow2531@gmail.com>
CC: uri@w3.org
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).

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

Best regards, Julian
Received on Friday, 26 February 2010 13:21:19 UTC

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