Ignore:
Timestamp:
May 27, 2011, 1:06:18 AM (9 years ago)
Author:
julian.reschke@…
Message:

apply RFC-Editor AUTH48 changes

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  
    371371  }
    372372  @bottom-center {
    373        content: "Expires November 2, 2011";
     373       content: "Expires November 28, 2011";
    374374  }
    375375  @bottom-right {
    … …  
    404404      <link rel="Chapter" href="#rfc.section.10" title="10 References">
    405405      <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">
    407407      <link rel="Appendix" title="C Alternative Approaches to Internationalization" href="#rfc.section.C">
    408408      <link rel="Appendix" title="D Advice on Generating Content-Disposition Header Fields" href="#rfc.section.D">
    … …  
    412412      <meta name="dct.creator" content="Reschke, J. F.">
    413413      <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">
    415415      <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.">
    416416      <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.">
    … …  
    430430               <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved)
    431431               </td>
    432                <td class="right">May 1, 2011</td>
     432               <td class="right">May 27, 2011</td>
    433433            </tr>
    434434            <tr>
    … …  
    437437            </tr>
    438438            <tr>
    439                <td class="left">Expires: November 2, 2011</td>
     439               <td class="left">Expires: November 28, 2011</td>
    440440               <td class="right"></td>
    441441            </tr>
    … …  
    466466         in progress”.
    467467      </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>
    469469      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    470470      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    492492         <li>7.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a></li>
    493493         <li>8.&nbsp;&nbsp;&nbsp;<a href="#iana.considerations">IANA Considerations</a><ul>
    494                <li>8.1&nbsp;&nbsp;&nbsp;<a href="#registry">Registry for Disposition Values and Parameter</a></li>
     494               <li>8.1&nbsp;&nbsp;&nbsp;<a href="#registry">Registry for Disposition Values and Parameters</a></li>
    495495               <li>8.2&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    496496            </ul>
    … …  
    504504         <li><a href="#rfc.authors">Author's Address</a></li>
    505505         <li>A.&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc2616">Changes from the RFC 2616 Definition</a></li>
    506          <li>B.&nbsp;&nbsp;&nbsp;<a href="#diffs.compared.to.rfc2183">Differences compared to RFC 2183</a></li>
     506         <li>B.&nbsp;&nbsp;&nbsp;<a href="#diffs.compared.to.rfc2183">Differences Compared to RFC 2183</a></li>
    507507         <li>C.&nbsp;&nbsp;&nbsp;<a href="#alternatives">Alternative Approaches to Internationalization</a><ul>
    508508               <li>C.1&nbsp;&nbsp;&nbsp;<a href="#alternatives.rfc2047">RFC 2047 Encoding</a></li>
    … …  
    533533      </ul>
    534534      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<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>):
    536536      </p>
    537537      <blockquote id="rfc.section.1.p.2" cite="http://tools.ietf.org/html/rfc2616#section-15.5">
    … …  
    541541      </blockquote>
    542542      <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 Extensions
    544          (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.
    545545      </p>
    546546      <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, such
     547         <p> <b>Note:</b> This document does not apply to Content-Disposition header fields appearing in payload bodies transmitted over HTTP, such
    548548            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>).
    549549         </p>
    … …  
    565565      <p id="rfc.section.3.p.3">Senders <em class="bcp14">MUST NOT</em> generate Content-Disposition header fields that are invalid.
    566566      </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 behaviour (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,
    568568         the default handling of invalid fields is to ignore them.
    569569      </p>
    … …  
    604604      <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.
    605605      </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 limited
     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 limited
    607607         use for filenames and is likely to be ignored by recipients.
    608608      </p>
    … …  
    630630         more expressive "filename*" parameter, and the "filename" parameter as fallback for legacy recipients (see <a href="#examples" title="Examples">Section&nbsp;5</a> for an example).
    631631      </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 desired
    633          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:
    634634      </p>
    635635      <ul>
    636636         <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 consider
     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, consider
    638638               the consequences of being able to overwrite well-known system locations (such as "/etc/passwd"). One strategy to achieve this
    639639               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 separator
    641                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 "/").
    642642            </p>
    643643         </li>
    644644         <li>
    645645            <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 which
     646               extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients that
    647647               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.
    648648            </p>
    … …  
    673673      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="examples" href="#examples">Examples</a></h1>
    674674      <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.html
     675      <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
    676676</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"
    678678         for a subsequent save operation:
    679679      </p>  <pre class="text">Content-Disposition: INLINE; FILENAME= "an example.html"
    680680</pre>  <p>Note: this uses the quoted-string form so that the space character can be included.</p>
    681681      <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;
    683683                     filename*= UTF-8''<b>%e2%82%ac</b>%20rates
    684684</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.
    685685      </p>
    686686      <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;
    688690                     filename="EURO rates";
    689691                     filename*=utf-8''<b>%e2%82%ac</b>%20rates
    … …  
    697699      <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&nbsp;4.3</a>.
    698700      </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>).
    700702      </p>
    701703      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<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>&nbsp;<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>&nbsp;<a id="registry" href="#registry">Registry for Disposition Values and Parameters</a></h2>
    703705      <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
    704706         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>.
    … …  
    769771         <tr>
    770772            <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&nbsp;2183, August&nbsp;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&nbsp;2183, August&nbsp;1997.
    772774            </td>
    773775         </tr>
    … …  
    817819         </li>
    818820      </ul>
    819       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<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>&nbsp;<a id="diffs.compared.to.rfc2183" href="#diffs.compared.to.rfc2183">Differences Compared to RFC 2183</a></h1>
    820822      <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 does not implement these, thus they have been omitted from this specification.
     823         majority of user agents do not implement these; thus, they have been omitted from this specification.
    822824      </p>
    823825      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="alternatives" href="#alternatives">Alternative Approaches to Internationalization</a></h1>
    … …  
    827829         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>).
    828830      </p>
    829       <p id="rfc.section.C.p.3">For completeness, the sections below describe the various approaches that have been tried, and explains how they are inferior
    830          to the RFC 5987 encoding used in this specification.
     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&nbsp;5987 encoding used in this specification.
    831833      </p>
    832834      <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a>&nbsp;<a id="alternatives.rfc2047" href="#alternatives.rfc2047">RFC 2047 Encoding</a></h2>
    833835      <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>:
    835837      </p>
    836838      <blockquote id="rfc.section.C.1.p.2" cite="http://tools.ietf.org/html/rfc2047#section-5">
    … …  
    845847      </p>
    846848      <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a>&nbsp;<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 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
     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
    848850         of the referring page, the user agent's locale, its configuration, and also the actual value of the parameter.
    849851      </p>
    850852      <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 actually
     853         to the user. For those user agents that do implement this, it is difficult to predict what character encoding they actually
    852854         expect.
    853855      </p>
    … …  
    856858         to be more likely to be the correct interpretation.
    857859      </p>
    858       <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>
     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>
    859861      <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a>&nbsp;<a id="alternatives.implementations" href="#alternatives.implementations">Implementations (to be removed by RFC Editor before publication)</a></h2>
    860862      <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
    … …  
    938940         </li>
    939941         <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 as an illegal path character.
     942            user agents, and "\" can be considered an illegal path character.
    941943         </li>
    942944         <li>Avoid using non-ASCII characters in the filename parameter. Although most existing implementations will decode them as ISO-8859-1,
    … …  
    957959         </li>
    958960      </ul>
    959       <p id="rfc.section.D.p.3">Note that this advice is based upon UA behaviour at the time of writing, and might be superseded. At the time of publication
     961      <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
    960962         of this document, &lt;<a href="http://purl.org/NET/http/content-disposition-tests">http://purl.org/NET/http/content-disposition-tests</a>&gt; provides an overview of current levels of support in various implementations.
    961963      </p>
    … …  
    10471049      </p>
    10481050      <h2 id="rfc.section.E.14"><a href="#rfc.section.E.14">E.14</a>&nbsp;<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>
    10501052      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    10511053      <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  
    2323  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
    2424  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
     25  <!ENTITY mdash "&#8212;">
    2526]>
    2627
    … …  
    7879<section title="Introduction" anchor="introduction">
    7980<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"/>)
    8183  but points out that it is not part of the HTTP/1.1 Standard (<xref target="RFC2616" x:fmt="sec" x:sec="15.5"/>):
    8284</t>
    … …  
    9092  This specification takes over the definition and registration of
    9193  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),
    9395  it fully defines a profile of the
    9496  features defined in the Multipurpose Internet Mail Extensions (MIME) variant (<xref target="RFC2183"/>) of the
    … …  
    98100<x:note>
    99101  <t>
    100     <x:h>Note:</x:h> this document does not apply to Content-Disposition
     102    <x:h>Note:</x:h> This document does not apply to Content-Disposition
    101103    header fields appearing in payload bodies transmitted over HTTP, such as
    102104    when using the media type "multipart/form-data" (<xref target="RFC2388"/>).
    … …  
    137139  Recipients &MAY; take steps to recover a usable field-value
    138140  from an invalid header field, but &SHOULD-NOT; reject the message outright,
    139   unless this is explicitly desirable behaviour (e.g., the implementation is a
     141  unless this is explicitly desirable behavior (e.g., the implementation is a
    140142  validator). As such, the default handling of invalid fields is to ignore them.
    141143</t>
    … …  
    195197</t>
    196198<t>
    197   Furthermore note that the format used for ext-value allows specifying a
     199  Furthermore, note that the format used for ext-value allows specifying a
    198200  natural language (e.g., "en"); this is of limited use for filenames and is
    199201  likely to be ignored by recipients.
    … …  
    248250<t>
    249251  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.
    251253  In particular:
    252254  <list style="symbols">
    253255    <x:lt><t>
    254256      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,
    256258      consider the consequences of being able to overwrite well-known system
    257259      locations (such as "/etc/passwd"). One strategy to achieve this is to
    258260      never trust folder name information in the filename parameter, for
    259       instance by stripping all but the last path segment and only consider the
    260       actual filename (where 'path segment' are the components of the field
     261      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
    261263      value delimited by the path separator characters "\" and "/").
    262264    </t></x:lt>
    … …  
    266268      extensions instead. Trusting the server-provided file extension could
    267269      introduce a privilege escalation when the saved file is later opened
    268       (consider ".exe"). Thus, recipients which make use of file extensions
     270      (consider ".exe"). Thus, recipients that make use of file extensions
    269271      to determine the media type &MUST; ensure that a file extension
    270272      is used that is safe, optimally matching the media type of the received
    … …  
    317319<figure>
    318320<preamble>
    319 Direct UA to show "save as" dialog, with a filename of "example.html": 
     321Direct the UA to show "save as" dialog, with a filename of "example.html": 
    320322</preamble>
    321323<artwork type="example">
    … …  
    324326<figure>
    325327<preamble>
    326 Direct UA to behave as if the Content-Disposition header field wasn't present,
     328Direct the UA to behave as if the Content-Disposition header field wasn't present,
    327329but to remember the filename "an example.html" for a subsequent save operation:
    328330</preamble>
    … …  
    337339<figure>
    338340<preamble>
    339 Direct UA to show "save as" dialog, with a filename containing the Unicode character  U+20AC (EURO SIGN):
     341Direct the UA to show "save as" dialog, with a filename containing the Unicode character  U+20AC (EURO SIGN):
    340342</preamble>
    341343<artwork type="example" x:indent-with="  ">
    … …  
    350352<figure>
    351353<preamble>
    352 Same as above, but adding the "filename" parameter for compatibility with
    353 user agents not implementing RFC 5987:
     354This example is the same as above, but adding the "filename" parameter for
     355compatibility with user agents not implementing RFC 5987:
    354356</preamble>
    355357<artwork type="example" x:indent-with="  ">
    … …  
    385387</t>
    386388<t>
    387   Furthermore, implementers also ought to be aware of the Security
    388   Considerations applying 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"/>
    389391  (see <xref target="RFC5987" x:fmt="sec" x:sec="5"/>).
    390392</t>
    … …  
    393395<section title="IANA Considerations" anchor="iana.considerations">
    394396
    395 <section title="Registry for Disposition Values and Parameter" anchor="registry">
     397<section title="Registry for Disposition Values and Parameters" anchor="registry">
    396398<t>
    397399  This specification does not introduce any changes to the registration
    … …  
    566568        <address><email>sdorner@qualcomm.com</email></address>
    567569      </author>
    568       <author initials="K." surname="Moore" fullname="Keith Moore">
     570      <author initials="K." surname="Moore" fullname="Keith Moore" role="editor">
    569571        <organization>Department of Computer Science</organization>
    570572        <address><email>moore@cs.utk.edu</email></address>
    … …  
    710712</section>
    711713
    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">
    713715<t>
    714716  <xref target="RFC2183" x:fmt="of" x:sec="2"/> defines several additional
    715717  disposition parameters: "creation-date", "modification-date",
    716   "quoted-date-time", and "size". The majority of user agents does not implement
    717   these, thus they 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.
    718720</t>
    719721</section>
    … …  
    734736<t>
    735737  For completeness, the sections below describe the various approaches that
    736   have been tried, and explains how they are inferior to the RFC 5987
     738  have been tried, and explain how they are inferior to the RFC&#160;5987
    737739  encoding used in this specification.
    738740</t>
    … …  
    742744  RFC 2047 defines an encoding mechanism for
    743745  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 &mdash; see <xref target="RFC2047" x:fmt="of" x:sec="5"/>: 
    745747</t>
    746748<x:blockquote cite="http://tools.ietf.org/html/rfc2047#section-5">
    … …  
    763765<section title="Percent Encoding" anchor="alternatives.percent">
    764766<t>
    765   Some user agents accept percent encoded (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>)
     767  Some user agents accept percent-encoded (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>)
    766768  sequences of characters. The character encoding being used for decoding
    767769  depends on various factors, including the encoding of the referring page,
    … …  
    772774  In practice, this is hard to use because those user agents that do not
    773775  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 character
     776  user agents that do implement this, it is difficult to predict what character
    775777  encoding they actually expect.
    776778</t>
    … …  
    784786</t>
    785787<t>
    786   As with the approaches above, this is not interoperable and furthermore
     788  As with the approaches above, this is not interoperable and, furthermore,
    787789  risks misinterpreting the actual value.
    788790</t>
    … …  
    875877    <t>Avoid including the "\" character in the quoted-string form of the
    876878    filename parameter, as escaping is not implemented by some user agents,
    877     and can be considered as an illegal path character.</t>
     879    and "\" can be considered an illegal path character.</t>
    878880    <t>Avoid using non-ASCII characters in the filename parameter. Although
    879881    most existing implementations will decode them as ISO-8859-1, some
    … …  
    905907</t>
    906908<t>
    907   Note that this advice is based upon UA behaviour at the time of writing, and
     909  Note that this advice is based upon UA behavior at the time of writing, and
    908910  might be superseded. At the time of publication of this document,
    909911  <eref target="http://purl.org/NET/http/content-disposition-tests"/> provides
    … …  
    11011103<section title="Since draft-ietf-httpbis-content-disp-09" anchor="changes.since.09">
    11021104<t>
    1103   None yet.
     1105  Editorial changes made during RFC-Editor AUTH48 phase.
    11041106</t>
    11051107</section>
Note: See TracChangeset for help on using the changeset viewer.