Changeset 1016 for draft-ietf-httpbis-content-disp
- Timestamp:
- 21/09/10 07:54:16 (12 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
r1013 r1016 401 401 <meta name="dct.creator" content="Reschke, J. F."> 402 402 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-content-disp-latest"> 403 <meta name="dct.issued" scheme="ISO8601" content="2010-09- 16">403 <meta name="dct.issued" scheme="ISO8601" content="2010-09-21"> 404 404 <meta name="dct.abstract" content="HTTP/1.1 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."> 405 405 <meta name="description" content="HTTP/1.1 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."> … … 419 419 <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved) 420 420 </td> 421 <td class="right">September 16, 2010</td>421 <td class="right">September 21, 2010</td> 422 422 </tr> 423 423 <tr> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: March 2 0, 2011</td>428 <td class="left">Expires: March 25, 2011</td> 429 429 <td class="right"></td> 430 430 </tr> … … 455 455 in progress”. 456 456 </p> 457 <p>This Internet-Draft will expire on March 2 0, 2011.</p>457 <p>This Internet-Draft will expire on March 25, 2011.</p> 458 458 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 459 459 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 534 534 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.field.definition" href="#header.field.definition">Header Field Definition</a></h1> 535 535 <p id="rfc.section.3.p.1">The Content-Disposition response header field is used to convey additional information about how to process the response payload, 536 and also can be used to attach additional metadata, such as the filename .536 and also can be used to attach additional metadata, such as the filename to use when saving the response payload locally. 537 537 </p> 538 538 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> Grammar … … 561 561 </p> <pre class="inline"> ext-value = <ext-value, defined in <a href="#RFC5987" id="rfc.xref.RFC5987.2"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, <a href="http://tools.ietf.org/html/rfc5987#section-3.2">Section 3.2</a>> 562 562 </pre><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="disposition.type" href="#disposition.type">Disposition Type</a></h2> 563 <p id="rfc.section.3.2.p.1">If the disposition type matches "attachment" (case-insensitively), this indicates that the user agent should not display the564 response, but directly enter a "save as..." dialog.563 <p id="rfc.section.3.2.p.1">If the disposition type matches "attachment" (case-insensitively), this indicates that the user agent should prompt the user 564 to save the response locally, rather than process it normally (as per its media type). 565 565 </p> 566 566 <p id="rfc.section.3.2.p.2">On the other hand, if it matches "inline" (case-insensitively), this implies default processing.</p> … … 591 591 <li> 592 592 <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 593 extension could introduce a privilege escalation when later on the file is opened locally (consider ".exe"). Thus, recipients594 needto ensure that a file extension is used that is safe, optimally matching the media type of the received payload.593 extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients need 594 to ensure that a file extension is used that is safe, optimally matching the media type of the received payload. 595 595 </p> 596 596 </li> … … 668 668 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> Acknowledgements 669 669 </h1> 670 <p id="rfc.section.8.p.1">Thanks to Rolf Eike Beer, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen, and Henrik Nordstrom for their valuable feedback.</p> 670 <p id="rfc.section.8.p.1">Thanks to Rolf Eike Beer, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen, Henrik Nordstrom, and Mark Nottingham for their 671 valuable feedback. 672 </p> 671 673 <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References 672 674 </h1> -
draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.xml
r1013 r1016 117 117 The Content-Disposition response header field is used to convey additional 118 118 information about how to process the response payload, and also can be used 119 to attach additional metadata, such as the filename. 119 to attach additional metadata, such as the filename to use when saving the 120 response payload locally. 120 121 </t> 121 122 … … 154 155 <section title="Disposition Type" anchor="disposition.type"> 155 156 <t> 156 If the disposition type matches "attachment" (case-insensitively), this indicates that the user agent should not display the response, 157 but directly enter a "save as..." dialog. 158 </t> 159 <t> 160 On the other hand, if it matches "inline" (case-insensitively), this implies default processing. 161 </t> 162 <t> 163 Unknown or unhandled disposition types &SHOULD; be handled the same way as "attachment" 164 (see also <xref target="RFC2183" x:fmt="," x:sec="2.8"/>). 157 If the disposition type matches "attachment" (case-insensitively), this 158 indicates that the user agent should prompt the user to save the response 159 locally, rather than process it normally (as per its media type). 160 </t> 161 <t> 162 On the other hand, if it matches "inline" (case-insensitively), this implies 163 default processing. 164 </t> 165 <t> 166 Unknown or unhandled disposition types &SHOULD; be handled the same way as 167 "attachment" (see also <xref target="RFC2183" x:fmt="," x:sec="2.8"/>). 165 168 </t> 166 169 </section> … … 207 210 to hold type information in the file system, but rely on filename 208 211 extensions instead. Trusting the server-provided file extension could 209 introduce a privilege escalation when later on the file is opened locally212 introduce a privilege escalation when the saved file is later opened 210 213 (consider ".exe"). Thus, recipients need to ensure that a file extension 211 214 is used that is safe, optimally matching the media type of the received … … 358 361 <t> 359 362 Thanks to Rolf Eike Beer, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen, 360 and Henrik Nordstrom for their valuable feedback.363 Henrik Nordstrom, and Mark Nottingham for their valuable feedback. 361 364 </t> 362 365 </section>
Note: See TracChangeset
for help on using the changeset viewer.