- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 26 Feb 2010 14:20:39 +0100
- 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