Changeset 1293 for draft-ietf-httpbis-content-disp
- Timestamp:
- May 27, 2011, 1:06:18 AM (9 years ago)
- Location:
- draft-ietf-httpbis-content-disp/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.html
r1276 r1293 371 371 } 372 372 @bottom-center { 373 content: "Expires November 2 , 2011";373 content: "Expires November 28, 2011"; 374 374 } 375 375 @bottom-right { … … 404 404 <link rel="Chapter" href="#rfc.section.10" title="10 References"> 405 405 <link rel="Appendix" title="A Changes from the RFC 2616 Definition" href="#rfc.section.A"> 406 <link rel="Appendix" title="B Differences compared to RFC 2183" href="#rfc.section.B">406 <link rel="Appendix" title="B Differences Compared to RFC 2183" href="#rfc.section.B"> 407 407 <link rel="Appendix" title="C Alternative Approaches to Internationalization" href="#rfc.section.C"> 408 408 <link rel="Appendix" title="D Advice on Generating Content-Disposition Header Fields" href="#rfc.section.D"> … … 412 412 <meta name="dct.creator" content="Reschke, J. F."> 413 413 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-content-disp-latest"> 414 <meta name="dct.issued" scheme="ISO8601" content="2011-05- 01">414 <meta name="dct.issued" scheme="ISO8601" content="2011-05-27"> 415 415 <meta name="dct.abstract" content="RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects."> 416 416 <meta name="description" content="RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects."> … … 430 430 <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved) 431 431 </td> 432 <td class="right">May 1, 2011</td>432 <td class="right">May 27, 2011</td> 433 433 </tr> 434 434 <tr> … … 437 437 </tr> 438 438 <tr> 439 <td class="left">Expires: November 2 , 2011</td>439 <td class="left">Expires: November 28, 2011</td> 440 440 <td class="right"></td> 441 441 </tr> … … 466 466 in progress”. 467 467 </p> 468 <p>This Internet-Draft will expire on November 2 , 2011.</p>468 <p>This Internet-Draft will expire on November 28, 2011.</p> 469 469 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 470 470 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 492 492 <li>7. <a href="#security.considerations">Security Considerations</a></li> 493 493 <li>8. <a href="#iana.considerations">IANA Considerations</a><ul> 494 <li>8.1 <a href="#registry">Registry for Disposition Values and Parameter </a></li>494 <li>8.1 <a href="#registry">Registry for Disposition Values and Parameters</a></li> 495 495 <li>8.2 <a href="#header.field.registration">Header Field Registration</a></li> 496 496 </ul> … … 504 504 <li><a href="#rfc.authors">Author's Address</a></li> 505 505 <li>A. <a href="#changes.from.rfc2616">Changes from the RFC 2616 Definition</a></li> 506 <li>B. <a href="#diffs.compared.to.rfc2183">Differences compared to RFC 2183</a></li>506 <li>B. <a href="#diffs.compared.to.rfc2183">Differences Compared to RFC 2183</a></li> 507 507 <li>C. <a href="#alternatives">Alternative Approaches to Internationalization</a><ul> 508 508 <li>C.1 <a href="#alternatives.rfc2047">RFC 2047 Encoding</a></li> … … 533 533 </ul> 534 534 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 535 <p id="rfc.section.1.p.1">RFC 2616 defines the Content-Disposition response header field in <a href="http://tools.ietf.org/html/rfc2616#section-19.5.1">Section 19.5.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>,but points out that it is not part of the HTTP/1.1 Standard (<a href="http://tools.ietf.org/html/rfc2616#section-15.5" id="rfc.xref.RFC2616.2">Section 15.5</a>):535 <p id="rfc.section.1.p.1">RFC 2616 defines the Content-Disposition response header field (<a href="http://tools.ietf.org/html/rfc2616#section-19.5.1">Section 19.5.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) but points out that it is not part of the HTTP/1.1 Standard (<a href="http://tools.ietf.org/html/rfc2616#section-15.5" id="rfc.xref.RFC2616.2">Section 15.5</a>): 536 536 </p> 537 537 <blockquote id="rfc.section.1.p.2" cite="http://tools.ietf.org/html/rfc2616#section-15.5"> … … 541 541 </blockquote> 542 542 <p id="rfc.section.1.p.3">This specification takes over the definition and registration of Content-Disposition, as used in HTTP. Based on interoperability 543 testing with existing User Agents, it fully defines a profile of the features defined in the Multipurpose Internet Mail Extensions544 (MIME) variant (<a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>) of the header field, and also clarifies internationalization aspects.543 testing with existing user agents (UAs), it fully defines a profile of the features defined in the Multipurpose Internet Mail 544 Extensions (MIME) variant (<a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>) of the header field, and also clarifies internationalization aspects. 545 545 </p> 546 546 <div class="note" id="rfc.section.1.p.4"> 547 <p> <b>Note:</b> this document does not apply to Content-Disposition header fields appearing in payload bodies transmitted over HTTP, such547 <p> <b>Note:</b> This document does not apply to Content-Disposition header fields appearing in payload bodies transmitted over HTTP, such 548 548 as when using the media type "multipart/form-data" (<a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>). 549 549 </p> … … 565 565 <p id="rfc.section.3.p.3">Senders <em class="bcp14">MUST NOT</em> generate Content-Disposition header fields that are invalid. 566 566 </p> 567 <p id="rfc.section.3.p.4">Recipients <em class="bcp14">MAY</em> take steps to recover a usable field-value from an invalid header field, but <em class="bcp14">SHOULD NOT</em> reject the message outright, unless this is explicitly desirable behavio ur (e.g., the implementation is a validator). As such,567 <p id="rfc.section.3.p.4">Recipients <em class="bcp14">MAY</em> take steps to recover a usable field-value from an invalid header field, but <em class="bcp14">SHOULD NOT</em> reject the message outright, unless this is explicitly desirable behavior (e.g., the implementation is a validator). As such, 568 568 the default handling of invalid fields is to ignore them. 569 569 </p> … … 604 604 <p id="rfc.section.4.1.p.5">Note that due to the rules for implied linear whitespace (<a href="http://tools.ietf.org/html/rfc2616#section-2.1">Section 2.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.8"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>), <em class="bcp14">OPTIONAL</em> whitespace can appear between words (token or quoted-string) and separator characters. 605 605 </p> 606 <p id="rfc.section.4.1.p.6">Furthermore note that the format used for ext-value allows specifying a natural language (e.g., "en"); this is of limited606 <p id="rfc.section.4.1.p.6">Furthermore, note that the format used for ext-value allows specifying a natural language (e.g., "en"); this is of limited 607 607 use for filenames and is likely to be ignored by recipients. 608 608 </p> … … 630 630 more expressive "filename*" parameter, and the "filename" parameter as fallback for legacy recipients (see <a href="#examples" title="Examples">Section 5</a> for an example). 631 631 </p> 632 <p id="rfc.section.4.3.p.5">It is essential that recipients treat the specified filename as advisory only, thus be very careful in extracting the desired633 information. In particular:632 <p id="rfc.section.4.3.p.5">It is essential that recipients treat the specified filename as advisory only, and thus be very careful in extracting the 633 desired information. In particular: 634 634 </p> 635 635 <ul> 636 636 <li> 637 <p>Recipients <em class="bcp14">MUST NOT</em> be able to write into any location other than one to which they are specifically entitled. To illustrate the problem consider637 <p>Recipients <em class="bcp14">MUST NOT</em> be able to write into any location other than one to which they are specifically entitled. To illustrate the problem, consider 638 638 the consequences of being able to overwrite well-known system locations (such as "/etc/passwd"). One strategy to achieve this 639 639 is to never trust folder name information in the filename parameter, for instance by stripping all but the last path segment 640 and only consider the actual filename (where 'path segment' are the components of the field value delimited by the path separator641 characters "\" and "/").640 and only considering the actual filename (where 'path segment' are the components of the field value delimited by the path 641 separator characters "\" and "/"). 642 642 </p> 643 643 </li> 644 644 <li> 645 645 <p>Many platforms do not use Internet Media Types (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>) to hold type information in the file system, but rely on filename extensions instead. Trusting the server-provided file 646 extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients which646 extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients that 647 647 make use of file extensions to determine the media type <em class="bcp14">MUST</em> ensure that a file extension is used that is safe, optimally matching the media type of the received payload. 648 648 </p> … … 673 673 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="examples" href="#examples">Examples</a></h1> 674 674 <div id="rfc.figure.u.4"></div> 675 <p>Direct UA to show "save as" dialog, with a filename of "example.html":</p> <pre class="text">Content-Disposition: Attachment; filename=example.html675 <p>Direct the UA to show "save as" dialog, with a filename of "example.html":</p> <pre class="text">Content-Disposition: Attachment; filename=example.html 676 676 </pre><div id="rfc.figure.u.5"></div> 677 <p>Direct UA to behave as if the Content-Disposition header field wasn't present, but to remember the filename "an example.html"677 <p>Direct the UA to behave as if the Content-Disposition header field wasn't present, but to remember the filename "an example.html" 678 678 for a subsequent save operation: 679 679 </p> <pre class="text">Content-Disposition: INLINE; FILENAME= "an example.html" 680 680 </pre> <p>Note: this uses the quoted-string form so that the space character can be included.</p> 681 681 <div id="rfc.figure.u.6"></div> 682 <p>Direct UA to show "save as" dialog, with a filename containing the Unicode character U+20AC (EURO SIGN):</p> <pre class="text">Content-Disposition: attachment;682 <p>Direct the UA to show "save as" dialog, with a filename containing the Unicode character U+20AC (EURO SIGN):</p> <pre class="text">Content-Disposition: attachment; 683 683 filename*= UTF-8''<b>%e2%82%ac</b>%20rates 684 684 </pre> <p>Here, the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.4"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a> is also used to encode the non-ISO-8859-1 character. 685 685 </p> 686 686 <div id="rfc.figure.u.7"></div> 687 <p>Same as above, but adding the "filename" parameter for compatibility with user agents not implementing RFC 5987:</p> <pre class="text">Content-Disposition: attachment; 687 <p>This example is the same as above, but adding the "filename" parameter for compatibility with user agents not implementing 688 RFC 5987: 689 </p> <pre class="text">Content-Disposition: attachment; 688 690 filename="EURO rates"; 689 691 filename*=utf-8''<b>%e2%82%ac</b>%20rates … … 697 699 <p id="rfc.section.7.p.1">Using server-supplied information for constructing local filenames introduces many risks. These are summarized in <a href="#disposition.parameter.filename" title="Disposition Parameter: 'Filename'">Section 4.3</a>. 698 700 </p> 699 <p id="rfc.section.7.p.2">Furthermore, implementers also ought to be aware of the Security Considerations applying to HTTP (see <a href="http://tools.ietf.org/html/rfc2616#section-15">Section 15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>), and also the parameter encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.6"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a> (see <a href="http://tools.ietf.org/html/rfc5987#section-5" id="rfc.xref.RFC5987.7">Section 5</a>).701 <p id="rfc.section.7.p.2">Furthermore, implementers ought to be aware of the security considerations applying to HTTP (see <a href="http://tools.ietf.org/html/rfc2616#section-15">Section 15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.9"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>), and also the parameter encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.6"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a> (see <a href="http://tools.ietf.org/html/rfc5987#section-5" id="rfc.xref.RFC5987.7">Section 5</a>). 700 702 </p> 701 703 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="iana.considerations" href="#iana.considerations">IANA Considerations</a></h1> 702 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="registry" href="#registry">Registry for Disposition Values and Parameter </a></h2>704 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="registry" href="#registry">Registry for Disposition Values and Parameters</a></h2> 703 705 <p id="rfc.section.8.1.p.1">This specification does not introduce any changes to the registration procedures for disposition values and parameters that 704 706 are defined in <a href="http://tools.ietf.org/html/rfc2183#section-9">Section 9</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.5"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>. … … 769 771 <tr> 770 772 <td class="reference"><b id="RFC2183">[RFC2183]</b></td> 771 <td class="top"><a href="mailto:rens@century.com" title="New Century Systems">Troost, R.</a>, <a href="mailto:sdorner@qualcomm.com" title="QUALCOMM Incorporated">Dorner, S.</a>, and <a href="mailto:moore@cs.utk.edu" title="Department of Computer Science">K. Moore </a>, “<a href="http://tools.ietf.org/html/rfc2183">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a>”, RFC 2183, August 1997.773 <td class="top"><a href="mailto:rens@century.com" title="New Century Systems">Troost, R.</a>, <a href="mailto:sdorner@qualcomm.com" title="QUALCOMM Incorporated">Dorner, S.</a>, and <a href="mailto:moore@cs.utk.edu" title="Department of Computer Science">K. Moore, Ed.</a>, “<a href="http://tools.ietf.org/html/rfc2183">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a>”, RFC 2183, August 1997. 772 774 </td> 773 775 </tr> … … 817 819 </li> 818 820 </ul> 819 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="diffs.compared.to.rfc2183" href="#diffs.compared.to.rfc2183">Differences compared to RFC 2183</a></h1>821 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="diffs.compared.to.rfc2183" href="#diffs.compared.to.rfc2183">Differences Compared to RFC 2183</a></h1> 820 822 <p id="rfc.section.B.p.1"> <a href="http://tools.ietf.org/html/rfc2183#section-2">Section 2</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.7"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> defines several additional disposition parameters: "creation-date", "modification-date", "quoted-date-time", and "size". The 821 majority of user agents do es not implement these, thusthey have been omitted from this specification.823 majority of user agents do not implement these; thus, they have been omitted from this specification. 822 824 </p> 823 825 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="alternatives" href="#alternatives">Alternative Approaches to Internationalization</a></h1> … … 827 829 Track specifies exactly one solution (<a href="#RFC2231" id="rfc.xref.RFC2231.1"><cite title="MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations">[RFC2231]</cite></a>, clarified and profiled for HTTP in <a href="#RFC5987" id="rfc.xref.RFC5987.9"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>). 828 830 </p> 829 <p id="rfc.section.C.p.3">For completeness, the sections below describe the various approaches that have been tried, and explain show they are inferior830 to the RFC 831 <p id="rfc.section.C.p.3">For completeness, the sections below describe the various approaches that have been tried, and explain how they are inferior 832 to the RFC 5987 encoding used in this specification. 831 833 </p> 832 834 <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a> <a id="alternatives.rfc2047" href="#alternatives.rfc2047">RFC 2047 Encoding</a></h2> 833 835 <p id="rfc.section.C.1.p.1">RFC 2047 defines an encoding mechanism for header fields, but this encoding is not supposed to be used for header field parameters 834 -see <a href="http://tools.ietf.org/html/rfc2047#section-5">Section 5</a> of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>:836 — see <a href="http://tools.ietf.org/html/rfc2047#section-5">Section 5</a> of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>: 835 837 </p> 836 838 <blockquote id="rfc.section.C.1.p.2" cite="http://tools.ietf.org/html/rfc2047#section-5"> … … 845 847 </p> 846 848 <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a> <a id="alternatives.percent" href="#alternatives.percent">Percent Encoding</a></h2> 847 <p id="rfc.section.C.2.p.1">Some user agents accept percent 849 <p id="rfc.section.C.2.p.1">Some user agents accept percent-encoded (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.1">Section 2.1</a>) sequences of characters. The character encoding being used for decoding depends on various factors, including the encoding 848 850 of the referring page, the user agent's locale, its configuration, and also the actual value of the parameter. 849 851 </p> 850 852 <p id="rfc.section.C.2.p.2">In practice, this is hard to use because those user agents that do not support it will display the escaped character sequence 851 to the user. For those user agents that do implement this it is difficult to predict what character encoding they actually853 to the user. For those user agents that do implement this, it is difficult to predict what character encoding they actually 852 854 expect. 853 855 </p> … … 856 858 to be more likely to be the correct interpretation. 857 859 </p> 858 <p id="rfc.section.C.3.p.2">As with the approaches above, this is not interoperable and furthermorerisks misinterpreting the actual value.</p>860 <p id="rfc.section.C.3.p.2">As with the approaches above, this is not interoperable and, furthermore, risks misinterpreting the actual value.</p> 859 861 <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a> <a id="alternatives.implementations" href="#alternatives.implementations">Implementations (to be removed by RFC Editor before publication)</a></h2> 860 862 <p id="rfc.section.C.4.p.1">Unfortunately, as of March 2011, neither the encoding defined in RFCs 2231 and 5987, nor any of the alternate approaches discussed … … 938 940 </li> 939 941 <li>Avoid including the "\" character in the quoted-string form of the filename parameter, as escaping is not implemented by some 940 user agents, and can be considered asan illegal path character.942 user agents, and "\" can be considered an illegal path character. 941 943 </li> 942 944 <li>Avoid using non-ASCII characters in the filename parameter. Although most existing implementations will decode them as ISO-8859-1, … … 957 959 </li> 958 960 </ul> 959 <p id="rfc.section.D.p.3">Note that this advice is based upon UA behavio ur at the time of writing, and might be superseded. At the time of publication961 <p id="rfc.section.D.p.3">Note that this advice is based upon UA behavior at the time of writing, and might be superseded. At the time of publication 960 962 of this document, <<a href="http://purl.org/NET/http/content-disposition-tests">http://purl.org/NET/http/content-disposition-tests</a>> provides an overview of current levels of support in various implementations. 961 963 </p> … … 1047 1049 </p> 1048 1050 <h2 id="rfc.section.E.14"><a href="#rfc.section.E.14">E.14</a> <a id="changes.since.09" href="#changes.since.09">Since draft-ietf-httpbis-content-disp-09</a></h2> 1049 <p id="rfc.section.E.14.p.1"> None yet.</p>1051 <p id="rfc.section.E.14.p.1">Editorial changes made during RFC-Editor AUTH48 phase.</p> 1050 1052 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1051 1053 <p class="noprint"><a href="#rfc.index.C">C</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.U">U</a> -
draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.xml
r1276 r1293 23 23 <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>"> 24 24 <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>"> 25 <!ENTITY mdash "—"> 25 26 ]> 26 27 … … 78 79 <section title="Introduction" anchor="introduction"> 79 80 <t> 80 RFC 2616 defines the Content-Disposition response header field in <xref target="RFC2616" x:fmt="of" x:sec="19.5.1"/>, 81 RFC 2616 defines the Content-Disposition response header field 82 (<xref target="RFC2616" x:fmt="of" x:sec="19.5.1"/>) 81 83 but points out that it is not part of the HTTP/1.1 Standard (<xref target="RFC2616" x:fmt="sec" x:sec="15.5"/>): 82 84 </t> … … 90 92 This specification takes over the definition and registration of 91 93 Content-Disposition, as used in HTTP. 92 Based on interoperability testing with existing User Agents,94 Based on interoperability testing with existing user agents (UAs), 93 95 it fully defines a profile of the 94 96 features defined in the Multipurpose Internet Mail Extensions (MIME) variant (<xref target="RFC2183"/>) of the … … 98 100 <x:note> 99 101 <t> 100 <x:h>Note:</x:h> this document does not apply to Content-Disposition102 <x:h>Note:</x:h> This document does not apply to Content-Disposition 101 103 header fields appearing in payload bodies transmitted over HTTP, such as 102 104 when using the media type "multipart/form-data" (<xref target="RFC2388"/>). … … 137 139 Recipients &MAY; take steps to recover a usable field-value 138 140 from an invalid header field, but &SHOULD-NOT; reject the message outright, 139 unless this is explicitly desirable behavio ur (e.g., the implementation is a141 unless this is explicitly desirable behavior (e.g., the implementation is a 140 142 validator). As such, the default handling of invalid fields is to ignore them. 141 143 </t> … … 195 197 </t> 196 198 <t> 197 Furthermore note that the format used for ext-value allows specifying a199 Furthermore, note that the format used for ext-value allows specifying a 198 200 natural language (e.g., "en"); this is of limited use for filenames and is 199 201 likely to be ignored by recipients. … … 248 250 <t> 249 251 It is essential that recipients treat the specified filename as advisory 250 only, thus be very careful in extracting the desired information.252 only, and thus be very careful in extracting the desired information. 251 253 In particular: 252 254 <list style="symbols"> 253 255 <x:lt><t> 254 256 Recipients &MUST-NOT; be able to write into any location other than one 255 to which they are specifically entitled. To illustrate the problem 257 to which they are specifically entitled. To illustrate the problem, 256 258 consider the consequences of being able to overwrite well-known system 257 259 locations (such as "/etc/passwd"). One strategy to achieve this is to 258 260 never trust folder name information in the filename parameter, for 259 instance by stripping all but the last path segment and only consider the260 actual filename (where 'path segment' are the components of the field261 instance by stripping all but the last path segment and only considering 262 the actual filename (where 'path segment' are the components of the field 261 263 value delimited by the path separator characters "\" and "/"). 262 264 </t></x:lt> … … 266 268 extensions instead. Trusting the server-provided file extension could 267 269 introduce a privilege escalation when the saved file is later opened 268 (consider ".exe"). Thus, recipients whichmake use of file extensions270 (consider ".exe"). Thus, recipients that make use of file extensions 269 271 to determine the media type &MUST; ensure that a file extension 270 272 is used that is safe, optimally matching the media type of the received … … 317 319 <figure> 318 320 <preamble> 319 Direct UA to show "save as" dialog, with a filename of "example.html":321 Direct the UA to show "save as" dialog, with a filename of "example.html": 320 322 </preamble> 321 323 <artwork type="example"> … … 324 326 <figure> 325 327 <preamble> 326 Direct UA to behave as if the Content-Disposition header field wasn't present,328 Direct the UA to behave as if the Content-Disposition header field wasn't present, 327 329 but to remember the filename "an example.html" for a subsequent save operation: 328 330 </preamble> … … 337 339 <figure> 338 340 <preamble> 339 Direct UA to show "save as" dialog, with a filename containing the Unicode character U+20AC (EURO SIGN):341 Direct the UA to show "save as" dialog, with a filename containing the Unicode character U+20AC (EURO SIGN): 340 342 </preamble> 341 343 <artwork type="example" x:indent-with=" "> … … 350 352 <figure> 351 353 <preamble> 352 Same as above, but adding the "filename" parameter for compatibility with 353 user agents not implementing RFC 5987:354 This example is the same as above, but adding the "filename" parameter for 355 compatibility with user agents not implementing RFC 5987: 354 356 </preamble> 355 357 <artwork type="example" x:indent-with=" "> … … 385 387 </t> 386 388 <t> 387 Furthermore, implementers also ought to be aware of the Security388 Considerationsapplying to HTTP (see <xref target="RFC2616" x:fmt="of" x:sec="15"/>), and also the parameter encoding defined in <xref target="RFC5987"/>389 Furthermore, implementers ought to be aware of the security considerations 390 applying to HTTP (see <xref target="RFC2616" x:fmt="of" x:sec="15"/>), and also the parameter encoding defined in <xref target="RFC5987"/> 389 391 (see <xref target="RFC5987" x:fmt="sec" x:sec="5"/>). 390 392 </t> … … 393 395 <section title="IANA Considerations" anchor="iana.considerations"> 394 396 395 <section title="Registry for Disposition Values and Parameter " anchor="registry">397 <section title="Registry for Disposition Values and Parameters" anchor="registry"> 396 398 <t> 397 399 This specification does not introduce any changes to the registration … … 566 568 <address><email>sdorner@qualcomm.com</email></address> 567 569 </author> 568 <author initials="K." surname="Moore" fullname="Keith Moore" >570 <author initials="K." surname="Moore" fullname="Keith Moore" role="editor"> 569 571 <organization>Department of Computer Science</organization> 570 572 <address><email>moore@cs.utk.edu</email></address> … … 710 712 </section> 711 713 712 <section title="Differences compared to RFC 2183" anchor="diffs.compared.to.rfc2183">714 <section title="Differences Compared to RFC 2183" anchor="diffs.compared.to.rfc2183"> 713 715 <t> 714 716 <xref target="RFC2183" x:fmt="of" x:sec="2"/> defines several additional 715 717 disposition parameters: "creation-date", "modification-date", 716 "quoted-date-time", and "size". The majority of user agents do esnot implement717 these , thusthey have been omitted from this specification.718 "quoted-date-time", and "size". The majority of user agents do not implement 719 these; thus, they have been omitted from this specification. 718 720 </t> 719 721 </section> … … 734 736 <t> 735 737 For completeness, the sections below describe the various approaches that 736 have been tried, and explain s how they are inferior to the RFC5987738 have been tried, and explain how they are inferior to the RFC 5987 737 739 encoding used in this specification. 738 740 </t> … … 742 744 RFC 2047 defines an encoding mechanism for 743 745 header fields, but this encoding is not supposed to be used for 744 header field parameters -see <xref target="RFC2047" x:fmt="of" x:sec="5"/>:746 header field parameters — see <xref target="RFC2047" x:fmt="of" x:sec="5"/>: 745 747 </t> 746 748 <x:blockquote cite="http://tools.ietf.org/html/rfc2047#section-5"> … … 763 765 <section title="Percent Encoding" anchor="alternatives.percent"> 764 766 <t> 765 Some user agents accept percent 767 Some user agents accept percent-encoded (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>) 766 768 sequences of characters. The character encoding being used for decoding 767 769 depends on various factors, including the encoding of the referring page, … … 772 774 In practice, this is hard to use because those user agents that do not 773 775 support it will display the escaped character sequence to the user. For those 774 user agents that do implement this it is difficult to predict what character776 user agents that do implement this, it is difficult to predict what character 775 777 encoding they actually expect. 776 778 </t> … … 784 786 </t> 785 787 <t> 786 As with the approaches above, this is not interoperable and furthermore788 As with the approaches above, this is not interoperable and, furthermore, 787 789 risks misinterpreting the actual value. 788 790 </t> … … 875 877 <t>Avoid including the "\" character in the quoted-string form of the 876 878 filename parameter, as escaping is not implemented by some user agents, 877 and can be considered asan illegal path character.</t>879 and "\" can be considered an illegal path character.</t> 878 880 <t>Avoid using non-ASCII characters in the filename parameter. Although 879 881 most existing implementations will decode them as ISO-8859-1, some … … 905 907 </t> 906 908 <t> 907 Note that this advice is based upon UA behavio ur at the time of writing, and909 Note that this advice is based upon UA behavior at the time of writing, and 908 910 might be superseded. At the time of publication of this document, 909 911 <eref target="http://purl.org/NET/http/content-disposition-tests"/> provides … … 1101 1103 <section title="Since draft-ietf-httpbis-content-disp-09" anchor="changes.since.09"> 1102 1104 <t> 1103 None yet.1105 Editorial changes made during RFC-Editor AUTH48 phase. 1104 1106 </t> 1105 1107 </section>
Note: See TracChangeset
for help on using the changeset viewer.