Date: Thu, 28 Mar 1996 17:05:57 -0500 To: montulli@netscape.com, jg@w3.org, mogul@pa.dec.com From: Danny Mayer Subject: Proposed addition of Content-Disposition to HTTP 1.1 spec Cc: rens@century.com, sdorner@qualcomm.com --=====================_828068757==_ Content-Type: text/plain; charset="us-ascii" I've made a first draft of a proposed addition of a Content-Disposition field to the HTTP 1.1 spec. This draft is based almost verbatim on Experimental RFC 1806. I am waiting for feedback from those authors on which changes I can and should make as a result of what they have heard over the last year since they issued the RFC. In the meantime Netscape has implemented at least a part of this in Netscape 2.0 and later so I've been successfully able to use this in my Software Distribution Server. The Draft follows. Danny --=====================_828068757==_ Content-Type: text/plain; charset="us-ascii" The Content-Disposition Header Field Content-Disposition is an optional header and allows the sender to indicate a default archival disposition; a filename. The optional "filename" parameter provides for this. This header field definition is based almost verbatim on Experimental RFC 1806 by R.Troost and S. Dorner, June 1995. It is desirable to keep the set of possible disposition types small and well defined, to avoid needless complexity. Even so, evolving usage will likely require the definition of additional disposition types or parameters, so the set of disposition values is extensible; see below. In the extended BNF notation of [RFC 822], the Content-Disposition header field is defined as follows: disposition := "Content-Disposition" ":" disposition-type *(";" disposition-parm) disposition-type := "inline" / "attachment" / extension-token ; values are not case-sensitive disposition-parm := filename-parm / parameter filename-parm := "filename" "=" value; `Extension-token', `parameter' and `value' are defined according to [RFC 822] and [RFC 1521]. 1.1 The Inline Disposition Type A bodypart should be marked `inline' if it is intended to be displayed automatically upon display of the message. Inline bodyparts should be presented in the order in which they occur, subject to the normal semantics of multipart messages. 1.2 The Attachment Disposition Type Bodyparts can be designated `attachment' to indicate that they are separate from the main body of the message, and that their display should not be automatic, but contingent upon some further action of the user. The receiver might instead present the user of a bitmap terminal with an iconic representation of the attachments, or, on character terminals, with a list of attachments from which the user could select for viewing or storage. 1.3 The Filename Parameter The sender may want to suggest a filename to be used if the entity is detached and stored in a separate file. If the receiver writes the entity to a file, the suggested filename should be used as a basis for the actual filename, where possible. It is important that the receiver not blindly use the suggested filename. The suggested filename should be checked (and possibly changed) to see that it conforms to local filesystem conventions, does not overwrite an existing file, and does not present a security problem (see Security Considerations below). The receiver should not respect any directory path information that may seem to be present in the filename parameter. The filename should be treated as a terminal component only. Portable specification of directory paths might possibly be done in the future via a separate Content-Disposition parameter, but no provision is made for it in this draft. Current [RFC 1521] grammar restricts parameter values (and hence Content-Disposition filenames) to US-ASCII. We recognize the great desirability of allowing arbitrary character sets in filenames, but it is beyond the scope of this document to define the necessary mechanisms. We expect that the basic [RFC 1521] `value' specification will someday be amended to allow use of non-US-ASCII characters, at which time the same mechanism should be used in the Content-Disposition filename parameter. Beyond the limitation to US-ASCII, the sender may wish to bear in mind the limitations of common filesystems. Many have severe length and character set restrictions. Short alphanumeric filenames are least likely to require modification by the receiving system. The presence of the filename parameter does not force an implementation to write the entity to a separate file. It is perfectly acceptable for implementations to leave the entity as part of the normal mail stream unless the user requests otherwise. As a consequence, the parameter may be used on any MIME entity, even `inline' ones. These will not normally be written to files, but the parameter could be used to provide a filename if the receiving user should choose to write the part to a file. 1.4 Future Extensions and Unrecognized Disposition Types In the likely event that new parameters or disposition types are needed, they should be registered with the Web Consortium (W3C). Once new disposition types and parameters are defined, there is of course the likelihood that implementations will see disposition types and parameters they do not understand. Furthermore, since x-tokens are allowed, implementations may also see entirely unregistered disposition types and parameters. Unrecognized parameters should be ignored. Unrecognized disposition types should be treated as `attachment'. The choice of `attachment' for unrecognized types is made because a sender who goes to the trouble of producing a Content-Disposition header with a new disposition type is more likely aiming for something more elaborate than inline presentation. Unless noted otherwise in the definition of a parameter, Content- Disposition parameters are valid for all dispositions. (In contrast to [RFC 1521] content-type parameters, which are defined on a per- content-type basis.) Thus, for example, the `filename' parameter still means the name of the file to which the part should be written, even if the disposition itself is unrecognized. 1.5 Content-Disposition and Multipart If a Content-Disposition header is used on a multipart body part, it applies to the multipart as a whole, not the individual subparts. The disposition types of the subparts do not need to be consulted until the multipart itself is presented. When the multipart is displayed, then the dispositions of the subparts should be respected. If the `inline' disposition is used, the multipart should be displayed as normal; however, an `attachment' subpart should require action from the user to display. If the `attachment' disposition is used, presentation of the multipart should not proceed without explicit user action. Once the user has chosen to display the multipart, the individual subpart dispositions should be consulted to determine how to present the subparts. 1.6 Content-Disposition and the Main Message It is permissible to use Content-Disposition on the main body of an [RFC 822] message. 1.7 Examples Here is a an example of a body part containing a JPEG image that is intended to be viewed by the user immediately: Content-Type: image/jpeg Content-Disposition: inline The following body part contains a JPEG image that should be displayed to the user only if the user requests it. If the JPEG is written to a file, the file should be named "genome.jpg": Content-Type: image/jpeg Content-Disposition: attachment; filename=genome.jpeg 1.8 Summary Content-Disposition takes one of two values, `inline' and `attachment'. 'Inline' indicates that the entity should be immediately displayed to the user, whereas `attachment' means that the user should take additional action to view the entity. The `filename' parameter can be used to suggest a filename for storing the bodypart, if the user wishes to store it in an external file. --=====================_828068757==_ Content-Type: text/plain; charset="us-ascii" =========================================================================== Danny Mayer Digital Equipment Corporation mayer@ljo.dec.com Littleton, MA 01460 =========================================================================== --=====================_828068757==_--