Issues-list item "DISPOSITION"

Issues-list item "DISPOSITION"

>From the Memphis minutes:

-- Content-Disposition will be added to the Appendix, as one
   of a group of common MIME headers about which implementors should
   be aware; Koen Holtman will draft the addition.

Here is a draft of the addition.  This text is based on 1806 and on
messages in the mailing list archive.  I have not tested this myself.


19.6.2.x Content-Disposition

   The Content-Disposition response-header field has been proposed as
   a means for the origin server to suggest a default filename if the
   user requests that the content is saved to a file.  This usage is
   derived from the definition of Content-Disposition in RFC 1806.

        content-disposition = "Content-Disposition" ":"
                              disposition-type *(";" disposition-parm)

        disposition-type = "attachment" | disp-extension-token

        disposition-parm = filename-parm | disp-extension-parm

        filename-parm = "filename" "=" quoted-string

        disp-extension-token = token

        disp-extension-parm = token "=" ( token | quoted-string )

   An example is

        Content-Disposition: attachment; filename="fname.ext"

   The receiving user agent 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.

   If this header is used in a response with the
   application/octet-stream content-type, the implied suggestion is
   that the user agent should not display the response, but directly
   enter a `save response as..'  dialog.


1806 lists some security considerations:

   Since this memo provides a way for the sender to suggest a filename,
   a receiving MUA must take care that the sender's suggested filename
   does not represent a hazard. Using UNIX as an example, some hazards
   would be:

          + Creating startup files (e.g., ".login").

          + Creating or overwriting system files (e.g.,
            "/etc/passwd").

          + Overwriting any existing file.

          + Placing executable files into any command search path
            (e.g., "~/bin/more").

          + Sending the file to a pipe (e.g., "| sh").

   In general, the receiving MUA should never name or place the file
   such that it will get interpreted or executed without the user
   explicitly initiating the action.

   It is very important to note that this is not an exhaustive list; it
   is intended as a small set of examples only.  Implementors must be
   alert to the potential hazards on their target systems.

I'm not sure what we should do about these.  Should we repeat them in
the security considerations section of 1.1, or is that not necessary?

Koen.

Received on Tuesday, 22 April 1997 01:05:17 UTC