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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Rich Tibbett-2
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
<[hidden email]>
 > 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


Reply | Threaded
Open this post in threaded view
|

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

Michael A. Puls II
On Thu, 13 Jan 2011 05:23:32 -0500, Rich Tibbett <[hidden email]> 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  
> <[hidden email]>
>  > 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