Problem statement / use cases
- Authors often want to provide users with downloaded versions of resources normally handled natively by the user’s browser
- Authors often must provide users with instructions for downloading even though authors cannot possibly be familiar with the user’s operating environment
- Authors may want to treat a resource as a type for embedding or linking different than the resource’s intrinsic type
- HTTP attempted to provide some solutions especially for tailoring the processing of content to an authors needs, however:
- because of the history of server-side and client-side http UAs, the content-type headers no longer serve this purpose
- any HTTP solution may not be available to all HTML authors: i.e., those who have no access to configure the server or are not using an HTTP server for delivery
- providing an HTML solution permits a single resource with only one representation to be processed in various ways while an HTTP solution requires either duplicating the resource or providing a symbolic or hard linking the same resource to provide different HTTP header metadata which may require additional network traffic as well
- new headers could be added to HTTP, but it still would not provide an HTML internal solution
A new download attribute
A new download attribute on the A, AREA and LINK elements that accepts the keywords: default, download, and download-dialog.
- 'default' is the default behavior for the UA given the MIME type of the resource
- 'download' causes the resource to be downloaded to the users’s default download directory, if defined, or forces a dialog otherwise
- 'download-dialog' causes a download to begin after first providing a user dialog to select a location for the download
UAs should provide a mechanism for users to disable automatic download of linked resources. UAs may also disable post processing for such downloaded resources by default to compensate for an insecure operating environment. For example, the issues surrounding malicious executable code security are better handled at the OS level through code-signing and other executable metadata, but UAs likely have no control over these issues. Within such insecure environments, it would be better to disable post processing by default and perhaps even disable these automatically downloads by default as well, though UAs should still provide a mechanism for users to re-enable such features.
A new processas attribute
A new processas attribute for the A, AREA, LINK, IMG, OBJECT, EMBED, VIDEO, AUDIO, and IFRAME elements. The attribute accepts a MIME Type or a keyword starting with an underscore. The defined keyword and the default value for the attribute when not explicitly specified or specified in a way unfamiliar to the UA is '_default'. The keyword '_default' indicates that the UA should process the resource just as it would normally process the resource following the processing algorithms in the HTML5 recommendation.
A specification of a MIMEType for the attribute instead indicates the UA must process the resource as if it is the MIMEType indicated by the processas attribute. On error, the UA must behave as if the resource is not available or indicate that the processing otherwise failed.
Authors should use the processas attribute sparingly and not to compensate for a misconfigured content type for a resource. Authors should ensure that file metadata, HTTP servers and operating environments are properly configured whenever these are within their abilities. The processas attribute is intended as a mechanism to treat the same resource as a different content type than its intrinsic content type and not as a mechanism to get around misconfigurations. However, as a last resort authors may use the processas attribute to compensate for environment and server misconfigurations.
Because both of these features have potential security concerns, UAs should provide an option to users to turn off such handling or to provide an alert to users warning of such security issues. This is particularly true when the UAs current environment might interpret the resource as an executable resource, though files may be moved from one environment to another or environment conditions may change so that some security concerns persist even for non-executable resources.
Discussion and evaluation
- Robert Burns initial message
- Michael Puls raises security concerns for downloads and a preference for solving it outside HTML
- Email explaining the original use case addressed by the HTTP content type headers (Roy T. Fielding)