W3C home > Mailing lists > Public > uri@w3.org > January 2011

Data URI handlng (was: Re: data URIs - filename and content-disposition)

From: Rich Tibbett <richt@opera.com>
Date: Thu, 13 Jan 2011 11:23:32 +0100
Message-ID: <4D2ED2A4.4020300@opera.com>
To: "Michael A. Puls II" <shadow2531@gmail.com>, "Julian Reschke" <julian.reschke@gmx.de>, uri@w3.org
Bumping this thread [1] in the hope someone could provide an update on 
its status.

On 24.02.2010 05:58, Michael A. Puls II wrote:
 > On Wed, 24 Feb 2010 05:34:55 -0500, Julian Reschke 
<julian.reschke@gmx.de>
 > wrote:
 >
 >  > On 24.02.2010 08:04, Michael A. Puls II wrote:
 >  >> I have a web page that's meant to run locally via file:. It uses 
XHR to
 >  >> load a vcard file. I then scan the file and convert it to a different
 >  >> text file format.
 >  >>
 >  >> I want to provide a save link for the new file format, so I 
decided to
 >  >> use a data URI. But, I want clicking on the data URI link to show an
 >  >> open/save dialog.
 >  >>
 >  >> I was able to do this by using <a
 >  >> href="data:application/octetstream;charset=utf-8,file_data"
 >  >> target="_blank">Save</a>.
 >  >>
 >  >> However, there are 2 problems.
 >  >>
 >  >> 1. There doesn't seem to be a way to give a filename hint.
 >  >>
 >  >> 2. I'd rather not use the octetstream mime type just to trigger a 
save
 >  >> dialog.
 >  >>
 >  >> With that said, I think it'd be awesome if you could do something 
like:
 >  >>
 >  >> <a
 >  >>
 > 
href="data:text/plain;charset=utf-8;filename=tada.txt;content-disposition=attachment,file_data">Save</a>. 

 >
 >  >>
 >  >>
 >  >> Setting aside the File API work, what about specifying those two 
in an
 >  >> update to the data URI RFC? Any vendors against implementing support
 > for
 >  >> it?
 >  >
 >  > Sounds like a nice idea; a few thoughts:
 >  >
 >  > - Given the sad state of data URI parsing in UAs, it may be hard to
 >  > deploy this extension; did you make tests whether existing UAs 
properly
 >  > parse (== ignore) new parameters?
 >
 > I tested a little in Safari, Opera, Firefox and IE. The extra params 
don't
 > seem to bother Firefox, Safari and Opera. I can't get data URIs to 
work at
 > all in IE atm, so...
 >
 > However, I didn't test complex filename values and the different ways you
 > can encode them. If I remember correctly, IE handles filename values
 > differently than the RFC and other browsers.
 >
 > So, I suspect that IE will probably give the most trouble. Although, I'm
 > sure I could find bugs in the other browsers too.
 >
 > But, I'm hopeful that it wouldn't be too hard for browsers to support.
 >
 >  > - An alternative would to define a way to include arbitrary 
headers; so
 >  > that Content-Disposition could be used as defined (but this may get
 >  > messy)
 >  >
 >  > - It would be nice to align this with the current IETF work on
 >  > rephrasing RFC 2231 and RFC 2183 for use in HTTP...
 >
 > Thanks
 >

So did any changes come out of this thread pertaining to RFC 2397 [2] or 
the RFCs mentioned above? Should it be discussed in the IETF and if so 
where?

We've been discussing around this exact issue within the W3C DAP Working 
Group and it would be great to know the exact, consistent behavior to 
expect on clicking a data URI [3].

Thanks,

Rich

[1] http://lists.w3.org/Archives/Public/uri/2010Feb/0060.html
[2] http://tools.ietf.org/html/rfc2397
[3] http://lists.w3.org/Archives/Public/public-device-apis/2011Jan/0031.html
Received on Thursday, 13 January 2011 10:24:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:14 UTC