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

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

From: Michael A. Puls II <shadow2531@gmail.com>
Date: Thu, 13 Jan 2011 18:15:55 -0500
To: "Julian Reschke" <julian.reschke@gmx.de>, uri@w3.org, "Rich Tibbett" <richt@opera.com>
Message-ID: <op.vo9r8sgi1ejg13@sandra-svwliu01>
On Thu, 13 Jan 2011 05:23:32 -0500, Rich Tibbett <richt@opera.com> wrote:

> 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?

No changes that I know of. But, I like the  
<http://lists.w3.org/Archives/Public/uri/2010Mar/0004.html> idea the best  
and am still waiting for comments on that.

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


-- 
Michael
Received on Thursday, 13 January 2011 23:16:24 UTC

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