rfc1806.txt

C/C++语言的CGI接口库


RFC 1806                  Content-Disposition                  June 1995


   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.

2.6  Content-Disposition and the Main Message

   It is permissible to use Content-Disposition on the main body of an
   [RFC 822] message.

3.  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
         Content-Description: just a small picture of me

         <jpeg data>

   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
         Content-Description: a complete map of the human genome

         <jpeg data>

   The following is an example of the use of the `attachment'
   disposition with a multipart body part.  The user should see text-
   part-1 immediately, then take some action to view multipart-2.  After
   taking action to view multipart-2, the user will see text-part-2
   right away, and be required to take action to view jpeg-1.  Subparts
   are indented for clarity; they would not be so indented in a real
   message.

         Content-Type: multipart/mixed; boundary=outer
         Content-Description: multipart-1

         --outer



Troost & Dorner               Experimental                      [Page 5]

RFC 1806                  Content-Disposition                  June 1995


           Content-Type: text/plain
           Content-Disposition: inline
           Content-Description: text-part-1

           Some text goes here

         --outer
           Content-Type: multipart/mixed; boundary=inner
           Content-Disposition: attachment
           Content-Description: multipart-2

           --inner
             Content-Type: text/plain
             Content-Disposition: inline
             Content-Description: text-part-2

             Some more text here.

           --inner
             Content-Type: image/jpeg
             Content-Disposition: attachment
             Content-Description: jpeg-1

             <jpeg data>
           --inner--
         --outer--

4.  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.

5.  Security Considerations

   There are security issues involved any time users exchange data.
   While these are not to be minimized, neither does this memo change
   the status quo in that regard, except in one instance.

   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:



Troost & Dorner               Experimental                      [Page 6]

RFC 1806                  Content-Disposition                  June 1995


          + 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.

6.  References

    [RFC 1521]
        Borenstein N., and N. Freed, "MIME (Multipurpose Internet
        Mail Extensions) Part One:  Mechanisms for Specifying and
        Describing the Format of Internet Message Bodies",
        RFC 1521, Bellcore, Innosoft, September 1993.

    [RFC 822]
        Crocker, D., "Standard for the Format of ARPA Internet
        Text Messages", STD 11, RFC 822, UDEL, August 1982.

7.  Acknowledgements

We gratefully acknowledge the help these people provided
during the preparation of this draft:

            Nathaniel Borenstein
            Ned Freed
            Keith Moore
            Dave Crocker
            Dan Pritchett









Troost & Dorner               Experimental                      [Page 7]

RFC 1806                  Content-Disposition                  June 1995


8.  Authors' Addresses

   Rens Troost
   New Century Systems
   324 East 41st Street #804
   New York, NY, 10017 USA

   Phone: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Steve Dorner
   QUALCOMM Incorporated
   6455 Lusk Boulevard
   San Diego, CA 92121
   USA

   EMail: [e-mail]
































Troost & Dorner               Experimental                      [Page 8]