HTTP already has Content-Disposition attachment.

I agree that this may not work well for everybody, but if we do consider this a problem, we should *also* make sure that we resolve the known interop problems with Content-Disposition (with respect to I18N of filenames) as well.

It does seem to me that this is already somewhat adequately addressed by Content-Disposition. It could probably be improved, but that would be an issue for the HTTPWG.

The problem with Content-Disposition is it does not provide an HTML solution for an HTML problem. A document authored to have links downloaded rather than loaded into a browsing context is something that belongs in HTML and not in a separate server parameter file. Within even the same HTML document an author might want to provide links to both a browser loaded and a downloaded version of the same resource.

You can already do that:

   <a href="resource">Resource</a>

The user can decide whether to download it, open it, open it in a new tab, or whatever. Why isn't that enough?

(In reply to comment #4)
> You can already do that:
> 
>    <a href="resource">Resource</a>
> 
> The user can decide whether to download it, open it, open it in a new tab, or
> whatever. Why isn't that enough?

1) Web site developers frequently do not want to rely on the ability of users to understand their browser's context menu.

2) Content-Disposition allows to specify a filename that is != the last path segment. This can help when the "original" URL space does not have "good" names, and also it can help with I18N.

That being said, the I18N problem for C-D needs to be worked on in some way; spec-wise, there's little left to do except a clarification that yes, you need to support a subset of RFC 2231. The biggest roadblock are two browsers not doing it, and I think it would be good if either the WHATWG or HTML 5 told them what they need to do.

Julian: Historically I've gotten into trouble whenever I've made specs say that other orthogonal specs are required, so I'm very hesitant to mention that.

I'm leaving this bug NEEDSINFO so that Rob can address the earlier comments.

(In reply to comment #6)
> Julian: Historically I've gotten into trouble whenever I've made specs say that
> other orthogonal specs are required, so I'm very hesitant to mention that.

As far as I can tell, the situation is like this:

- all major UAs support C-D in principle

- the experts seem to agree that RFC 2231 applies, and is what needs to be implemented

- there's also agreement that RFC 2231, when applied to HTTP, is overly complex, and a profile (UTF-8, no line folding) is totally sufficient

- as far as I recall, FF and Opera get this right; IE and Safari don't (see <https://bugs.webkit.org/show_bug.cgi?id=15287>, dunno how to access the associated radar bug entry).

- there is no interoperable way to have non-ASCII characters in the filename parameter, so sites need to resort to UA sniffing.

The question is: are we satisfied with the situation? If we aren't, what can we do to improve the situation?

I don't know that it's the HTMLWG's problem.

(In reply to comment #8)
> I don't know that it's the HTMLWG's problem.

So who's problem is it then? I thought one of the objectives of HTML 5 was to ensure interoperability between User Agents?

The HTTPWG's, I guess. Who works on the relevant RFC?

Interoperability should be the (only) concern of every working group. But only within the scope of the work of that working group. It shouldn't be the HTTP WG's job to make UAs interoperable for CSS and ODF, for example. Or the HTML WG's job to make UAs interoperable over HTTP. (HTML5 oversteps its bounds in an attempt to prevent cracks appearing between the specs, or to cover things that other working groups want to ignore, like content-sniffing, but ideally the specs would all be comprehensive and "flush", to extend the metaphor.)

(In reply to comment #10)
> The HTTPWG's, I guess. Who works on the relevant RFC?

Well, the RFCs already specify the solution. HTTPbis can potentially *clarify* it, but that's it.

The problem is that some browser vendors aren't listening.

> Interoperability should be the (only) concern of every working group. But only
> within the scope of the work of that working group. It shouldn't be the HTTP
> WG's job to make UAs interoperable for CSS and ODF, for example. Or the HTML
> WG's job to make UAs interoperable over HTTP. (HTML5 oversteps its bounds in an
> attempt to prevent cracks appearing between the specs, or to cover things that
> other working groups want to ignore, like content-sniffing, but ideally the
> specs would all be comprehensive and "flush", to extend the metaphor.)

Yes, in theory everything should be orthogonal, but in practice it isn't.

The really simple question is: what is needed to make Apple and Microsoft implement what's already specified? If the HTML WG (or the W3C in general) could help, that would be great.

> > The HTTPWG's, I guess. Who works on the relevant RFC?
> 
> Well, the RFCs already specify the solution. HTTPbis can potentially *clarify*
> it, but that's it.

Sure, but what WG is responsible for maintaining these RFCs, dealing with implementation feedback, etc?


> The really simple question is: what is needed to make Apple and Microsoft
> implement what's already specified?

Time, probably. Possibly you could accelerate it by giving them a good business reason to prioritise it (e.g. have some major site use it and break without it, or pay them large amounts of money).


> If the HTML WG (or the W3C in general) could help, that would be great.

I don't see any way we can influence the priority that a browser vendors gives a feature. On the contrary, with HTML5 it is the browser vendors who tell _me_ what the next priority item is, not vice versa.

> Time, probably. Possibly you could accelerate it by giving them a good business
> reason to prioritise it (e.g. have some major site use it and break without it,
> or pay them large amounts of money).

Believe me, that was tried years ago, but didn't succeed. Of course that was during a period where Microsoft was rejecting *any* bug report that wasn't security related.

If this bug could be solved by RFC 2231, MIME Headers or HTTP Headers, than I might be inclined to agree that it is not necessarily an issue of concern to the HTML WG. However, the currecnt draft often does touch on similar such issues that are probably not the concern of the HTML WG. So there is some precedent on Julians side here.

Having said that, I don't think this bug at can be addressed by RFC 2231, MIME headers nor HTTP headers. Rather authors need a way internal to HTML to alter the normal disposition (to borrow the term from RFC 2231) of a resource.

In comment #4, list item #1, Julian said what I would say: that is authors do not ant to always rely on the skills of users to provide an easy link for download of a resource. HTML should provide a way to do this. Not that the normal use of the content-disposition header provides an equivalent approach within a multi-part MIME document. The author shouldn't have to rely on the settings on the server or even require write-access to the resources directory just to provide a downloadable link. Also, its common for authors to provide links side-by-side one for download and one for loading in the browser window.

I agree that an HTML-level solution would be good and address cases where C-D doesn't work well.

That being said, the lack of interop for C-D alone shouldn't be taken as an argument for inventing something new. Instead, we should try to get C-D fixed.

(In reply to comment #15)
> I agree that an HTML-level solution would be good and address cases where C-D
> doesn't work well. 

I completely agree.

> That being said, the lack of interop for C-D alone shouldn't be taken as an
> argument for inventing something new. Instead, we should try to get C-D fixed.

Agreed again. This bug wasn't inspired by the lack of interoperability for C-D at all. I filed it to address the need for an HTML internal solution to the needs of authors to provide download links. Perhaps we should file a separate bug on the C-D interoperability problem and see if there's any way for the HTML5 draft to address that issue.

(In reply to comment #11)
> The problem is that some browser vendors aren't listening.
> The really simple question is: what is needed to make Apple and Microsoft
> implement what's already specified? If the HTML WG (or the W3C in general)
> could help, that would be great.

The HTML Working Group has no means to compel or "make" Apple or
Microsoft or other browser vendors to implement something they may
have deliberately chosen not to implement -- particularly for
cases where they may have a (business) reason of their own for
doing so. I'm not saying that's the case for this specific issue,
but just that it's the case in general.

As far as how the HTML WG can help for issues like this, the main
way the HTML WG can help is by providing an open public forum
in which representatives from browser vendors are actively
participating and where there is perhaps some expectation on
browser vendors to respond in good faith to questions about issues
like this one (and some history of them doing so).

Which is all a long-winded way of saying that I think one way to
try to get Apple and Microsoft to address this issue is for you to
actually ask them on the public-html list for a response about it.

Related discussion: <http://moinmo.in/MoinMoinBugs/Non-ASCII%20attachment%20names%20corrupted%20on%20download>

More related discussion: <http://support.liferay.com/browse/LEP-3127>

So basically this is asking for something like a 'rel' value that causes the resource to be downloaded instead of opened, in the same way that 'target' values can be used to make something open in a new window instead of the same window?

(In reply to comment #20)
> So basically this is asking for something like a 'rel' value that causes the
> resource to be downloaded instead of opened, in the same way that 'target'
> values can be used to make something open in a new window instead of the same
> window?

Sort of.

The disposition ("inline" vs "attachment") seems to fit better with target ("_download"?).

However, in addition, a filename attribute would be needed.

If the request here is indeed something that would be simply addressed by a target="_download" attribute value and a filename="" attribute, then the next steps are to do some research to determine if this is something that authors really want, finding out and documenting why what they have now doesn't work, how they are working around those problems, and getting implementations to commit to implement the feature or getting experimental implementations.

Personally I hate it when pages try to control where a link is going to open, and I think Content-Disposition handles the filename problem fine (though the relevant spec should probably be updated to be clearer about how to handle the aforementioned issues, and the relevant working group should write test cases and generally do a better job of supporting their spec). But if there is sufficient evidence that this is really needed, and if UAs want to implement it, then we should indeed add it.

(in reply to comment #22 and #21)
I think a target='_download' would probably be a decent solution. I'm not as clear why authors need control over the filename (either in http disposition headers or here). I can see why an email MIME part needs to attach filesystem metadata to an included file since there's no other place for that metadata. However, in the case of http or other URL-based delivery, all of that filesystem metadata is available already. The issue of providing a different filename might be a nice enhancement, but hardly a necessity.

Ok.

I'm marking this NEEDSINFO as we need the following information:
- whether this is something that authors really want
- why what they have now doesn't work and how they are working around those problems
- which implementations have committed to implementing the feature experimentally

(In reply to comment #24)

> Ok.

> I'm marking this NEEDSINFO as we need the following information:
> - whether this is something that authors really want
> - why what they have now doesn't work and how they are working around those
> problems

These points were included in the linked URL:
http://esw.w3.org/topic/HTML/LinkAndEmbeddingAttributes

In short, authors right now provide detailed platform specific instructions (wrong for anyone using a different platform) on how to click on the link to download the resource. Obviously using @target or anything like that need author discretion and authors should notify users of the non-standard handling of the link. But that shouldn't stop us from providing the functionality for users and authors

> - which implementations have committed to implementing the feature
> experimentally

Again, this is the same canned response you use to dismiss proposals when you can't think of anything else. Please stop using this tired old remark. It leads us to reverse the priority of constituencies, especially  on a feature like this that is fairly rudimentary to implement.

If it helps, I'll personally do what I have in my power to see that two implementations implement support for this markup.

Info needed, info provided!

I was really looking for objective data supporting these points rather than merely anecdotal evidence. The same kind of data as Philip provides to support his requests, for instance.

Regarding implementations, I ask no less of my own suggestions. If you don't agree with this approach to spec development, you are welcome to discuss it with the chairs.

Please let me know when there's an implementation and real data to support this feature request. I can't and won't do anything until that research is done and until implementation experience has been collected.

(In reply to comment #23)
> (in reply to comment #22 and #21)
> I think a target='_download' would probably be a decent solution. I'm not as
> clear why authors need control over the filename (either in http disposition
> headers or here). I can see why an email MIME part needs to attach filesystem
> metadata to an included file since there's no other place for that metadata.
> However, in the case of http or other URL-based delivery, all of that
> filesystem metadata is available already. The issue of providing a different
> filename might be a nice enhancement, but hardly a necessity.

The only available information for the filename would be the URI. That isn't sufficient in all cases, as:

- the URI namespace may not be defined in a way that allows exposing the filename (such as, when using numeric identifiers),

- there's no reliable way to map non-ASCII characters (we can't rely on non-ASCII characters to be encoded in UTF-8)

(In reply to comment #24)
> Ok.
> 
> I'm marking this NEEDSINFO as we need the following information:
> - whether this is something that authors really want

Many do. How do you measure the "really"? How many parties need to speak up?

> - why what they have now doesn't work and how they are working around those
> problems

As far as I can tell, the only mechanism that is currently available is Content-Disposition; and there is no workaround for the I18N interop problem.

(In reply to comment #28)
> 
> As far as I can tell, the only mechanism that is currently available is
> Content-Disposition; and there is no workaround for the I18N interop problem.
> 

The other work around often used by authors is to incorrectly describe the users environment to them such as: hold down the whatzit key and click on this link to download the file. Obviously this provides users with a clear understanding of what will happen, but it doesn't really speak to all users. A better approach is to provide an HTML solution that doesn't rely on author access to the resources server where content-disposition headers might change. That way the author can provide something like:

<a href='video.ogg' >View this video in this window</a> or <a href='video.ogg' target='_download' filename='afilename' >download it </a> for later.

(In reply to comment #27)
> The only available information for the filename would be the URI. That isn't
> sufficient in all cases, as:
> - the URI namespace may not be defined in a way that allows exposing the
> filename (such as, when using numeric identifiers),
> - there's no reliable way to map non-ASCII characters (we can't rely on
> non-ASCII characters to be encoded in UTF-8)

OK, that makes sense. I didn't think about that. However, two questions?

1. is there interoperability problems for UTF-8 percent encoded URL]s as recommended here: http://www.w3.org/International/O-URL-code.html
2. is anything being done in the http wg to get http headers updated to unicode transform or utf-8 specifically?

(In reply to comment #29)
> OK, that makes sense. I didn't think about that. However, two questions?
> 
> 1. is there interoperability problems for UTF-8 percent encoded URL]s as
> recommended here: http://www.w3.org/International/O-URL-code.html
> 2. is anything being done in the http wg to get http headers updated to unicode
> transform or utf-8 specifically?

1: No, I don't think so.

2: The HTTPbis working group is chartered to only clarify HTTP/1.1; unfortunately, this means the defaults for header encoding can not be changed. That being said: RFC2231 already describes how to represent non-ASCII characters in header parameters (as used for C-D); the only problem is that only 2 of the major 4 browsers implement this.

(In reply to comment #30)
> (In reply to comment #29)
> > 1. is there interoperability problems for UTF-8 percent encoded URL]s as
> > recommended here: http://www.w3.org/International/O-URL-code.html
> 
> 1: No, I don't think so.
> 
So, percent encoding the url of a file and providing target='_download' would provide complete international support then right? Adding a separate filename attribute or an optional _download('filename') might provide authors with more flexibility to create a default filename different from the resources served filename, but it would not be required for l18N support? I'm asking because I'm still trying to understand this issue.

And again I want to reiterate, that I'm not proposing this because of a deficiency in rfc 2231 support, rather I think we need support for this in HTML itself independent of HTTP solutions.

> So, percent encoding the url of a file and providing target='_download' would

...percent-escaping the UTF-8 encoding of a file name...

> provide complete international support then right? Adding a separate filename
> attribute or an optional _download('filename') might provide authors with more
> flexibility to create a default filename different from the resources served
> filename, but it would not be required for l18N support? I'm asking because I'm
> still trying to understand this issue.

Yes, I think that's correct.

> And again I want to reiterate, that I'm not proposing this because of a
> deficiency in rfc 2231 support, rather I think we need support for this in HTML
> itself independent of HTTP solutions.

Understood. I just think UAs should support RFC 2231 *first*, before focusing on new stuff (2 out of the 4 major UAs get it right, after all).

(In reply to comment #19)

MS on Sharepoint I18N: <http://www.microsoft.com/technet/prodtechnol/sppt/sharepnt/stsintl.mspx> -- recommends to configure the IE instances to "always send as UTF-8", which, as far as I recall, makes IE's behaviour with respect to C-D at least predictable.

(how much more evidence is needed???)

Feedback from Maciej Stachowiak on Content-Disposition and RFC 2231 style encoding:

> On Apple's behalf, I can tell you that this seems like a generally  
> useful feature and we don't know of any blocking issues in the RFCs  
> themselves. However, per Apple policy I cannot comment on specific  
> details of future releases. (I believe I said the same before).

-- <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-July/015352.html>

This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.