Changeset 2726 for draft-ietf-httpbis-content-disp/05
- Timestamp:
- 14/06/14 11:20:37 (7 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-content-disp/05/draft-ietf-httpbis-content-disp.html
r1119 r2726 2 2 PUBLIC "-//W3C//DTD HTML 4.01//EN"> 3 3 <html lang="en"> 4 <head profile="http:// www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">4 <head profile="http://dublincore.org/documents/2008/08/04/dc-html/"> 5 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 6 6 <title>Use of the Content-Disposition Header Field … … 33 33 body { 34 34 color: black; 35 font-family: verdana, helvetica, arial, sans-serif; 36 font-size: 10pt; 35 font-family: cambria, helvetica, arial, sans-serif; 36 font-size: 11pt; 37 margin-right: 2em; 37 38 } 38 39 cite { … … 42 43 margin-left: 2em; 43 44 } 44 dd {45 margin-right: 2em;46 }47 45 dl { 48 46 margin-left: 2em; 49 47 } 50 51 48 ul.empty { 52 49 list-style-type: none; … … 62 59 } 63 60 h1 { 64 font-size: 1 4pt;61 font-size: 130%; 65 62 line-height: 21pt; 66 63 page-break-after: avoid; … … 69 66 page-break-before: always; 70 67 } 71 h1 a {72 color: #333333;73 }74 68 h2 { 75 font-size: 12 pt;69 font-size: 120%; 76 70 line-height: 15pt; 77 71 page-break-after: avoid; 78 72 } 79 h3 , h4, h5, h6{80 font-size: 1 0pt;73 h3 { 74 font-size: 110%; 81 75 page-break-after: avoid; 82 76 } 83 h2 a, h3 a, h4 a, h5 a, h6 a { 77 h4, h5, h6 { 78 page-break-after: avoid; 79 } 80 h1 a, h2 a, h3 a, h4 a, h5 a, h6 a { 84 81 color: black; 85 82 } … … 89 86 li { 90 87 margin-left: 2em; 91 margin-right: 2em;92 88 } 93 89 ol { 94 90 margin-left: 2em; 95 margin-right: 2em; 91 } 92 ol.la { 93 list-style-type: lower-alpha; 94 } 95 ol.ua { 96 list-style-type: upper-alpha; 96 97 } 97 98 ol p { … … 100 101 p { 101 102 margin-left: 2em; 102 margin-right: 2em;103 103 } 104 104 pre { … … 106 106 background-color: lightyellow; 107 107 padding: .25em; 108 page-break-inside: avoid; 108 109 } 109 110 pre.text2 { … … 134 135 table.tt { 135 136 vertical-align: top; 137 border-color: gray; 138 } 139 table.tt th { 140 border-color: gray; 141 } 142 table.tt td { 143 border-color: gray; 144 } 145 table.all { 146 border-style: solid; 147 border-width: 2px; 136 148 } 137 149 table.full { 138 border-style: outset; 139 border-width: 1px; 140 } 141 table.headers { 142 border-style: outset; 143 border-width: 1px; 150 border-style: solid; 151 border-width: 2px; 144 152 } 145 153 table.tt td { 146 154 vertical-align: top; 147 155 } 156 table.all td { 157 border-style: solid; 158 border-width: 1px; 159 } 148 160 table.full td { 149 border-style: inset;161 border-style: none solid; 150 162 border-width: 1px; 151 163 } … … 153 165 vertical-align: top; 154 166 } 167 table.all th { 168 border-style: solid; 169 border-width: 1px; 170 } 155 171 table.full th { 156 border-style: inset;157 border-width: 1px ;172 border-style: solid; 173 border-width: 1px 1px 2px 1px; 158 174 } 159 175 table.headers th { 160 border-style: none none insetnone;161 border-width: 1px;176 border-style: none none solid none; 177 border-width: 2px; 162 178 } 163 179 table.left { … … 174 190 caption-side: bottom; 175 191 font-weight: bold; 176 font-size: 9pt;192 font-size: 10pt; 177 193 margin-top: .5em; 178 194 } … … 181 197 border-spacing: 1px; 182 198 width: 95%; 183 font-size: 1 0pt;199 font-size: 11pt; 184 200 color: white; 185 201 } … … 189 205 td.topnowrap { 190 206 vertical-align: top; 191 white-space: nowrap; 207 white-space: nowrap; 192 208 } 193 209 table.header td { … … 209 225 list-style: none; 210 226 margin-left: 1.5em; 211 margin-right: 0em;212 227 padding-left: 0em; 213 228 } … … 215 230 line-height: 150%; 216 231 font-weight: bold; 217 font-size: 10pt;218 232 margin-left: 0em; 219 margin-right: 0em;220 233 } 221 234 ul.toc li li { 222 235 line-height: normal; 223 236 font-weight: normal; 224 font-size: 9pt;237 font-size: 10pt; 225 238 margin-left: 0em; 226 margin-right: 0em;227 239 } 228 240 li.excluded { … … 231 243 ul p { 232 244 margin-left: 0em; 245 } 246 .title, .filename, h1, h2, h3, h4 { 247 font-family: candara, helvetica, arial, sans-serif; 248 } 249 samp, tt, code, pre { 250 font: consolas, monospace; 233 251 } 234 252 ul.ind, ul.ind ul { 235 253 list-style: none; 236 254 margin-left: 1.5em; 237 margin-right: 0em;238 255 padding-left: 0em; 239 256 page-break-before: avoid; … … 243 260 line-height: 200%; 244 261 margin-left: 0em; 245 margin-right: 0em;246 262 } 247 263 ul.ind li li { … … 249 265 line-height: 150%; 250 266 margin-left: 0em; 251 margin-right: 0em;252 267 } 253 268 .avoidbreak { … … 276 291 font-weight: bold; 277 292 text-align: center; 278 font-size: 9pt;293 font-size: 10pt; 279 294 } 280 295 .filename { 281 296 color: #333333; 297 font-size: 75%; 282 298 font-weight: bold; 283 font-size: 12pt;284 299 line-height: 21pt; 285 300 text-align: center; … … 288 303 font-weight: bold; 289 304 } 290 .hidden {291 display: none;292 }293 305 .left { 294 306 text-align: left; … … 298 310 } 299 311 .title { 300 color: #990000;301 font-size: 1 8pt;312 color: green; 313 font-size: 150%; 302 314 line-height: 18pt; 303 315 font-weight: bold; … … 305 317 margin-top: 36pt; 306 318 } 307 .vcardline {308 display: block;309 }310 319 .warning { 311 font-size: 1 4pt;320 font-size: 130%; 312 321 background-color: yellow; 313 322 } … … 318 327 display: none; 319 328 } 320 329 321 330 a { 322 331 color: black; … … 333 342 background-color: white; 334 343 vertical-align: top; 335 font-size: 1 2pt;336 } 337 338 ul.toc a: :after {344 font-size: 110%; 345 } 346 347 ul.toc a:nth-child(2)::after { 339 348 content: leader('.') target-counter(attr(href), page); 340 349 } 341 350 342 351 ul.ind li li a { 343 352 content: target-counter(attr(href), page); 344 353 } 345 354 346 355 .print2col { 347 356 column-count: 2; … … 353 362 @page { 354 363 @top-left { 355 content: "Internet-Draft"; 356 } 364 content: "Internet-Draft"; 365 } 357 366 @top-right { 358 content: "February 2011"; 359 } 367 content: "February 2011"; 368 } 360 369 @top-center { 361 content: "Content-Disposition in HTTP"; 362 } 370 content: "Content-Disposition in HTTP"; 371 } 363 372 @bottom-left { 364 content: "Reschke"; 365 } 373 content: "Reschke"; 374 } 366 375 @bottom-center { 367 content: "Expires August 21, 2011"; 368 } 376 content: "Expires August 21, 2011"; 377 } 369 378 @bottom-right { 370 content: "[Page " counter(page) "]"; 371 } 372 } 373 374 @page:first { 379 content: "[Page " counter(page) "]"; 380 } 381 } 382 383 @page:first { 375 384 @top-left { 376 385 content: normal; … … 401 410 <link rel="Appendix" title="C Alternative Approaches to Internationalization" href="#rfc.section.C"> 402 411 <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D"> 403 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1. 540, 2011-01-10 09:27:20, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">412 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 404 413 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 405 414 <meta name="dct.creator" content="Reschke, J. F."> … … 421 430 </tr> 422 431 <tr> 423 <td class="left">Updates: <a href="http ://tools.ietf.org/html/rfc2616">2616</a> (if approved)432 <td class="left">Updates: <a href="https://tools.ietf.org/html/rfc2616">2616</a> (if approved) 424 433 </td> 425 434 <td class="right">February 17, 2011</td> … … 436 445 </table> 437 446 <p class="title">Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)<br><span class="filename">draft-ietf-httpbis-content-disp-05</span></p> 438 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 447 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 439 448 <p>HTTP/1.1 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. 440 449 This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization 441 450 aspects. 442 </p> 443 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor before publication)</a></h1> 451 </p> 452 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor before publication)</a></h1> 444 453 <p>This specification is expected to replace the definition of Content-Disposition in the HTTP/1.1 specification, as currently 445 454 revised by the IETF HTTPbis working group. See also <<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/123">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/123</a>>. 446 </p> 455 </p> 447 456 <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org). The current issues 448 457 list is at <<a href="http://trac.tools.ietf.org/wg/httpbis/trac/query?component=content-disp">http://trac.tools.ietf.org/wg/httpbis/trac/query?component=content-disp</a>> and related documents (including fancy diffs) can be found at <<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>>. 449 </p> 458 </p> 450 459 <p>The changes in this draft are summarized in <a href="#changes.since.04" title="Since draft-ietf-httpbis-content-disp-04">Appendix D.9</a>. 451 </p>452 <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1>453 <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>454 <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute455 working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>.456 460 </p> 457 <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other 458 documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work 459 in progress”. 460 </p> 461 <p>This Internet-Draft will expire on August 21, 2011.</p> 462 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 463 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 464 <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights 465 and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License 466 text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified 467 BSD License. 468 </p> 461 <div id="rfc.status"> 462 <h1><a href="#rfc.status">Status of This Memo</a></h1> 463 <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p> 464 <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute 465 working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>. 466 </p> 467 <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other 468 documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work 469 in progress”. 470 </p> 471 <p>This Internet-Draft will expire on August 21, 2011.</p> 472 </div> 473 <div id="rfc.copyrightnotice"> 474 <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1> 475 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 476 <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights 477 and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License 478 text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified 479 BSD License. 480 </p> 481 </div> 469 482 <hr class="noprint"> 470 483 <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1> 471 484 <ul class="toc"> 472 <li> 1. <a href="#introduction">Introduction</a></li>473 <li> 2. <a href="#notational.conventions">Notational Conventions</a></li>474 <li> 3. <a href="#conformance.and.error.handling">Conformance and Error Handling</a></li>475 <li> 4. <a href="#header.field.definition">Header Field Definition</a><ul>476 <li> 4.1 <a href="#rfc.section.4.1">Grammar</a></li>477 <li> 4.2 <a href="#disposition.type">Disposition Type</a></li>478 <li> 4.3 <a href="#disposition.parameter.filename">Disposition Parameter: 'Filename'</a></li>479 <li> 4.4 <a href="#disposition.parameter.extensions">Disposition Parameter: Extensions</a></li>480 <li> 4.5 <a href="#extensibility">Extensibility</a></li>485 <li><a href="#rfc.section.1">1.</a> <a href="#introduction">Introduction</a></li> 486 <li><a href="#rfc.section.2">2.</a> <a href="#notational.conventions">Notational Conventions</a></li> 487 <li><a href="#rfc.section.3">3.</a> <a href="#conformance.and.error.handling">Conformance and Error Handling</a></li> 488 <li><a href="#rfc.section.4">4.</a> <a href="#header.field.definition">Header Field Definition</a><ul> 489 <li><a href="#rfc.section.4.1">4.1</a> <a href="#rfc.section.4.1">Grammar</a></li> 490 <li><a href="#rfc.section.4.2">4.2</a> <a href="#disposition.type">Disposition Type</a></li> 491 <li><a href="#rfc.section.4.3">4.3</a> <a href="#disposition.parameter.filename">Disposition Parameter: 'Filename'</a></li> 492 <li><a href="#rfc.section.4.4">4.4</a> <a href="#disposition.parameter.extensions">Disposition Parameter: Extensions</a></li> 493 <li><a href="#rfc.section.4.5">4.5</a> <a href="#extensibility">Extensibility</a></li> 481 494 </ul> 482 495 </li> 483 <li> 5. <a href="#examples">Examples</a></li>484 <li> 6. <a href="#i18n">Internationalization Considerations</a></li>485 <li> 7. <a href="#security.considerations">Security Considerations</a></li>486 <li> 8. <a href="#iana.considerations">IANA Considerations</a><ul>487 <li> 8.1 <a href="#registry">Registry for Disposition Values and Parameter</a></li>488 <li> 8.2 <a href="#header.field.registration">Header Field Registration</a></li>496 <li><a href="#rfc.section.5">5.</a> <a href="#examples">Examples</a></li> 497 <li><a href="#rfc.section.6">6.</a> <a href="#i18n">Internationalization Considerations</a></li> 498 <li><a href="#rfc.section.7">7.</a> <a href="#security.considerations">Security Considerations</a></li> 499 <li><a href="#rfc.section.8">8.</a> <a href="#iana.considerations">IANA Considerations</a><ul> 500 <li><a href="#rfc.section.8.1">8.1</a> <a href="#registry">Registry for Disposition Values and Parameter</a></li> 501 <li><a href="#rfc.section.8.2">8.2</a> <a href="#header.field.registration">Header Field Registration</a></li> 489 502 </ul> 490 503 </li> 491 <li> 9. <a href="#rfc.section.9">Acknowledgements</a></li>492 <li> 10. <a href="#rfc.references">References</a><ul>493 <li> 10.1 <a href="#rfc.references.1">Normative References</a></li>494 <li> 10.2 <a href="#rfc.references.2">Informative References</a></li>504 <li><a href="#rfc.section.9">9.</a> <a href="#rfc.section.9">Acknowledgements</a></li> 505 <li><a href="#rfc.section.10">10.</a> <a href="#rfc.references">References</a><ul> 506 <li><a href="#rfc.section.10.1">10.1</a> <a href="#rfc.references.1">Normative References</a></li> 507 <li><a href="#rfc.section.10.2">10.2</a> <a href="#rfc.references.2">Informative References</a></li> 495 508 </ul> 496 509 </li> 497 <li><a href="#rfc.authors">Author's Address</a></li> 498 <li>A. <a href="#changes.from.rfc2616">Changes from the RFC 2616 Definition</a></li> 499 <li>B. <a href="#diffs.compared.to.rfc2183">Differences compared to RFC 2183</a></li> 500 <li>C. <a href="#alternatives">Alternative Approaches to Internationalization</a><ul> 501 <li>C.1 <a href="#alternatives.rfc2047">RFC 2047 Encoding</a></li> 502 <li>C.2 <a href="#alternatives.percent">Percent Encoding</a></li> 503 <li>C.3 <a href="#alternatives.sniff">Encoding Sniffing</a></li> 504 <li>C.4 <a href="#alternatives.implementations">Implementations (to be removed by RFC Editor before publication)</a></li> 510 <li><a href="#rfc.section.A">A.</a> <a href="#changes.from.rfc2616">Changes from the RFC 2616 Definition</a></li> 511 <li><a href="#rfc.section.B">B.</a> <a href="#diffs.compared.to.rfc2183">Differences compared to RFC 2183</a></li> 512 <li><a href="#rfc.section.C">C.</a> <a href="#alternatives">Alternative Approaches to Internationalization</a><ul> 513 <li><a href="#rfc.section.C.1">C.1</a> <a href="#alternatives.rfc2047">RFC 2047 Encoding</a></li> 514 <li><a href="#rfc.section.C.2">C.2</a> <a href="#alternatives.percent">Percent Encoding</a></li> 515 <li><a href="#rfc.section.C.3">C.3</a> <a href="#alternatives.sniff">Encoding Sniffing</a></li> 516 <li><a href="#rfc.section.C.4">C.4</a> <a href="#alternatives.implementations">Implementations (to be removed by RFC Editor before publication)</a></li> 505 517 </ul> 506 518 </li> 507 <li> D. <a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul>508 <li> D.1 <a href="#rfc.section.D.1">Since draft-reschke-rfc2183-in-http-00</a></li>509 <li> D.2 <a href="#rfc.section.D.2">Since draft-reschke-rfc2183-in-http-01</a></li>510 <li> D.3 <a href="#rfc.section.D.3">Since draft-reschke-rfc2183-in-http-02</a></li>511 <li> D.4 <a href="#rfc.section.D.4">Since draft-reschke-rfc2183-in-http-03</a></li>512 <li> D.5 <a href="#changes.since.00">Since draft-ietf-httpbis-content-disp-00</a></li>513 <li> D.6 <a href="#changes.since.01">Since draft-ietf-httpbis-content-disp-01</a></li>514 <li> D.7 <a href="#changes.since.02">Since draft-ietf-httpbis-content-disp-02</a></li>515 <li> D.8 <a href="#changes.since.03">Since draft-ietf-httpbis-content-disp-03</a></li>516 <li> D.9 <a href="#changes.since.04">Since draft-ietf-httpbis-content-disp-04</a></li>519 <li><a href="#rfc.section.D">D.</a> <a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul> 520 <li><a href="#rfc.section.D.1">D.1</a> <a href="#rfc.section.D.1">Since draft-reschke-rfc2183-in-http-00</a></li> 521 <li><a href="#rfc.section.D.2">D.2</a> <a href="#rfc.section.D.2">Since draft-reschke-rfc2183-in-http-01</a></li> 522 <li><a href="#rfc.section.D.3">D.3</a> <a href="#rfc.section.D.3">Since draft-reschke-rfc2183-in-http-02</a></li> 523 <li><a href="#rfc.section.D.4">D.4</a> <a href="#rfc.section.D.4">Since draft-reschke-rfc2183-in-http-03</a></li> 524 <li><a href="#rfc.section.D.5">D.5</a> <a href="#changes.since.00">Since draft-ietf-httpbis-content-disp-00</a></li> 525 <li><a href="#rfc.section.D.6">D.6</a> <a href="#changes.since.01">Since draft-ietf-httpbis-content-disp-01</a></li> 526 <li><a href="#rfc.section.D.7">D.7</a> <a href="#changes.since.02">Since draft-ietf-httpbis-content-disp-02</a></li> 527 <li><a href="#rfc.section.D.8">D.8</a> <a href="#changes.since.03">Since draft-ietf-httpbis-content-disp-03</a></li> 528 <li><a href="#rfc.section.D.9">D.9</a> <a href="#changes.since.04">Since draft-ietf-httpbis-content-disp-04</a></li> 517 529 </ul> 518 530 </li> 519 531 <li><a href="#rfc.index">Index</a></li> 532 <li><a href="#rfc.authors">Author's Address</a></li> 520 533 </ul> 521 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 522 <p id="rfc.section.1.p.1">HTTP/1.1 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>): 523 </p> 524 <blockquote id="rfc.section.1.p.2" cite="http://tools.ietf.org/html/rfc2616#section-15.5"> 525 <p>Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks 526 for implementers. 527 </p> 528 </blockquote> 529 <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 530 testing with existing User Agents, it fully defines a profile of the features defined in the Multipurpose Internet Mail Extensions 531 (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. 532 </p> 533 <div class="note" id="rfc.section.1.p.4"> 534 <p> <b>Note:</b> this document does not apply to Content-Disposition header fields appearing in message payloads transmitted over HTTP, such 535 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>). 536 </p> 537 </div> 538 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="notational.conventions" href="#notational.conventions">Notational Conventions</a></h1> 539 <p id="rfc.section.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 540 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 541 </p> 542 <p id="rfc.section.2.p.2">This specification uses the augmented BNF notation defined in <a href="http://tools.ietf.org/html/rfc2616#section-2.1">Section 2.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, including its rules for implied linear whitespace (LWS). 543 </p> 544 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="conformance.and.error.handling" href="#conformance.and.error.handling">Conformance and Error Handling</a></h1> 545 <p id="rfc.section.3.p.1">This specification defines conformance criteria for both senders (usually, HTTP origin servers) and recipients (usually, HTTP 546 user agents) of the Content-Location header field. An implementation is considered conformant if it complies with all of the 547 requirements associated with its role. 548 </p> 549 <p id="rfc.section.3.p.2">This specification also defines certain forms of the header field-value to be invalid, using both ABNF and prose requirements, 550 but it does not define special handling of these invalid field-values. 551 </p> 552 <p id="rfc.section.3.p.3">Sending implementations <em class="bcp14">MUST NOT</em> generate Content-Location header fields that are invalid. 553 </p> 554 <p id="rfc.section.3.p.4">Consuming implementations <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, 555 the default handling of invalid fields is to ignore them. 556 </p> 557 <div id="rfc.iref.h.1"></div> 558 <div id="rfc.iref.c.1"></div> 559 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="header.field.definition" href="#header.field.definition">Header Field Definition</a></h1> 560 <p id="rfc.section.4.p.1">The Content-Disposition response header field is used to convey additional information about how to process the response payload, 561 and also can be used to attach additional metadata, such as the filename to use when saving the response payload locally. 562 </p> 563 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> Grammar 564 </h2> 565 <div id="rfc.figure.u.1"></div><pre class="inline"> content-disposition = "Content-Disposition" ":" 534 <div id="introduction"> 535 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a href="#introduction">Introduction</a></h1> 536 <p id="rfc.section.1.p.1">HTTP/1.1 defines the Content-Disposition response header field in <a href="https://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="https://tools.ietf.org/html/rfc2616#section-15.5" id="rfc.xref.RFC2616.2">Section 15.5</a>): 537 </p> 538 <blockquote id="rfc.section.1.p.2" cite="http://tools.ietf.org/html/rfc2616#section-15.5"> 539 <p>Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks 540 for implementers. 541 </p> 542 </blockquote> 543 <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 544 testing with existing User Agents, it fully defines a profile of the features defined in the Multipurpose Internet Mail Extensions 545 (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. 546 </p> 547 <div class="note" id="rfc.section.1.p.4"> 548 <p><b>Note:</b> this document does not apply to Content-Disposition header fields appearing in message payloads transmitted over HTTP, such 549 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>). 550 </p> 551 </div> 552 </div> 553 <div id="notational.conventions"> 554 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#notational.conventions">Notational Conventions</a></h1> 555 <p id="rfc.section.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 556 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 557 </p> 558 <p id="rfc.section.2.p.2">This specification uses the augmented BNF notation defined in <a href="https://tools.ietf.org/html/rfc2616#section-2.1">Section 2.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, including its rules for implied linear whitespace (LWS). 559 </p> 560 </div> 561 <div id="conformance.and.error.handling"> 562 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#conformance.and.error.handling">Conformance and Error Handling</a></h1> 563 <p id="rfc.section.3.p.1">This specification defines conformance criteria for both senders (usually, HTTP origin servers) and recipients (usually, HTTP 564 user agents) of the Content-Location header field. An implementation is considered conformant if it complies with all of the 565 requirements associated with its role. 566 </p> 567 <p id="rfc.section.3.p.2">This specification also defines certain forms of the header field-value to be invalid, using both ABNF and prose requirements, 568 but it does not define special handling of these invalid field-values. 569 </p> 570 <p id="rfc.section.3.p.3">Sending implementations <em class="bcp14">MUST NOT</em> generate Content-Location header fields that are invalid. 571 </p> 572 <p id="rfc.section.3.p.4">Consuming implementations <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, 573 the default handling of invalid fields is to ignore them. 574 </p> 575 </div> 576 <div id="header.field.definition"> 577 <div id="rfc.iref.h.1"></div> 578 <div id="rfc.iref.c.1"></div> 579 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#header.field.definition">Header Field Definition</a></h1> 580 <p id="rfc.section.4.p.1">The Content-Disposition response header field is used to convey additional information about how to process the response payload, 581 and also can be used to attach additional metadata, such as the filename to use when saving the response payload locally. 582 </p> 583 <div> 584 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> Grammar 585 </h2> 586 <div id="rfc.figure.u.1"></div><pre class="inline"> content-disposition = "Content-Disposition" ":" 566 587 disposition-type *( ";" disposition-parm ) 567 588 … … 578 599 | ext-token "=" ext-value 579 600 ext-token = <the characters in token, followed by "*"> 580 </pre><div id="rfc.figure.u.2"></div> 581 <p>Defined in <a href="#RFC2616" id="rfc.xref.RFC2616.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>:582 </p> <pre class="inline"> token = <token, defined in <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a>>583 quoted-string = <quoted-string, defined in <a href="#RFC2616" id="rfc.xref.RFC2616.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http ://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a>>584 value = <value, defined in <a href="#RFC2616" id="rfc.xref.RFC2616.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http ://tools.ietf.org/html/rfc2616#section-3.6">Section 3.6</a>>601 </pre><div id="rfc.figure.u.2"></div> 602 <p>Defined in <a href="#RFC2616" id="rfc.xref.RFC2616.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>: 603 </p><pre class="inline"> token = <token, defined in <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a>> 604 quoted-string = <quoted-string, defined in <a href="#RFC2616" id="rfc.xref.RFC2616.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a>> 605 value = <value, defined in <a href="#RFC2616" id="rfc.xref.RFC2616.7"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-3.6">Section 3.6</a>> 585 606 ; token | quoted-string 586 607 587 </pre><div id="rfc.figure.u.3"></div> 588 <p>Defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>:589 </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>>608 </pre><div id="rfc.figure.u.3"></div> 609 <p>Defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>: 610 </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="https://tools.ietf.org/html/rfc5987#section-3.2">Section 3.2</a>> 590 611 </pre><p id="rfc.section.4.1.p.4">Header field values with multiple instances of the same parameter name are invalid.</p> 591 <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>), OPTIONAL whitespace can appear between words (token or quoted-string) and separator characters. 592 </p> 593 <p id="rfc.section.4.1.p.6">Furthermore note that the format used for ext-value allows specifying a natural language; this is of limited use for filenames 594 and is likely to be ignored by recipients. 595 </p> 596 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="disposition.type" href="#disposition.type">Disposition Type</a></h2> 597 <p id="rfc.section.4.2.p.1">If the disposition type matches "attachment" (case-insensitively), this indicates that the user agent should prompt the user 598 to save the response locally, rather than process it normally (as per its media type). 599 </p> 600 <p id="rfc.section.4.2.p.2">On the other hand, if it matches "inline" (case-insensitively), this implies default processing.</p> 601 <p id="rfc.section.4.2.p.3">Unknown or unhandled disposition types <em class="bcp14">SHOULD</em> be handled by recipients the same way as "attachment" (see also <a href="#RFC2183" id="rfc.xref.RFC2183.2"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, <a href="http://tools.ietf.org/html/rfc2183#section-2.8">Section 2.8</a>). 602 </p> 603 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="disposition.parameter.filename" href="#disposition.parameter.filename">Disposition Parameter: 'Filename'</a></h2> 604 <p id="rfc.section.4.3.p.1">The parameters "filename" and "filename*", to be matched case-insensitively, provide information on how to construct a filename 605 for storing the message payload. 606 </p> 607 <p id="rfc.section.4.3.p.2">Depending on the disposition type, this information might be used right away (in the "save as..." interaction caused for the 608 "attachment" disposition type), or later on (for instance, when the user decides to save the contents of the current page 609 being displayed). 610 </p> 611 <p id="rfc.section.4.3.p.3">The parameters "filename" and "filename*" differ only in that "filename*" uses the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.3"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, allowing the use of characters not present in the ISO-8859-1 character set (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>). 612 </p> 613 <p id="rfc.section.4.3.p.4">Many user agent implementations predating this specification do not understand the "filename*" parameter. Therefore, when 614 both "filename" and "filename*" are present in a single header field value, recipients <em class="bcp14">SHOULD</em> pick "filename*" and ignore "filename". This way, senders can avoid special-casing specific user agents by sending both the 615 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). 616 </p> 617 <p id="rfc.section.4.3.p.5">It is essential that user agents treat the specified filename as advisory only, thus be very careful in extracting the desired 618 information. In particular: 619 </p> 620 <ul> 621 <li> 622 <p>When the value contains path separator characters ("\" or "/"), recipients <em class="bcp14">SHOULD</em> ignore all but the last path segment. This prevents unintentional overwriting of well-known file system locations (such as 623 "/etc/passwd"). 624 </p> 625 </li> 626 <li> 627 <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 628 extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients need 629 to ensure that a file extension is used that is safe, optimally matching the media type of the received payload. 630 </p> 631 </li> 632 <li> 633 <p>Recipients are advised to strip or replace character sequences that are known to cause confusion both in user interfaces and 634 in filenames, such as control characters and leading and trailing whitespace. 635 </p> 636 </li> 637 <li> 638 <p>Other aspects recipients need to be aware of are names that have a special meaning in the file system or in shell commands, 639 such as "." and "..", "~", "|", and also device names. 640 </p> 641 </li> 642 </ul> 643 <div class="note" id="rfc.section.4.3.p.6"> 644 <p> <b>Note:</b> Many user agents do not properly handle escape characters when using the quoted-string form. Furthermore, some user agents 645 erroneously try to perform unescaping of "percent" escapes (see <a href="#alternatives.percent" title="Percent Encoding">Appendix C.2</a>), and thus might misinterpret filenames containing the percent character followed by two hex digits. 646 </p> 647 </div> 648 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="disposition.parameter.extensions" href="#disposition.parameter.extensions">Disposition Parameter: Extensions</a></h2> 649 <p id="rfc.section.4.4.p.1">To enable future extensions, recipients <em class="bcp14">SHOULD</em> ignore unrecognized parameters (see also <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, <a href="http://tools.ietf.org/html/rfc2183#section-2.8">Section 2.8</a>). 650 </p> 651 <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a> <a id="extensibility" href="#extensibility">Extensibility</a></h2> 652 <p id="rfc.section.4.5.p.1">Note that <a href="http://tools.ietf.org/html/rfc2183#section-9">Section 9</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.4"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> defines IANA registries both for disposition types and disposition parameters. This registry is shared by different protocols 653 using Content-Disposition, such as MIME and HTTP. Therefore, not all registered values may make sense in the context of HTTP. 654 </p> 655 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="examples" href="#examples">Examples</a></h1> 656 <div id="rfc.figure.u.4"></div> 657 <p>Direct UA to show "save as" dialog, with a filename of "example.html":</p> <pre class="text">Content-Disposition: Attachment; filename=example.html 658 </pre><div id="rfc.figure.u.5"></div> 659 <p>Direct UA to behave as if the Content-Disposition header field wasn't present, but to remember the filename "an example.html" 660 for a subsequent save operation: 661 </p> <pre class="text">Content-Disposition: INLINE; FILENAME= "an example.html" 662 </pre> <p>Note: this uses the quoted-string form so that the space character can be included.</p> 663 <div id="rfc.figure.u.6"></div> 664 <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; 612 <p id="rfc.section.4.1.p.5">Note that due to the rules for implied linear whitespace (<a href="https://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>), OPTIONAL whitespace can appear between words (token or quoted-string) and separator characters. 613 </p> 614 <p id="rfc.section.4.1.p.6">Furthermore note that the format used for ext-value allows specifying a natural language; this is of limited use for filenames 615 and is likely to be ignored by recipients. 616 </p> 617 </div> 618 <div id="disposition.type"> 619 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a href="#disposition.type">Disposition Type</a></h2> 620 <p id="rfc.section.4.2.p.1">If the disposition type matches "attachment" (case-insensitively), this indicates that the user agent should prompt the user 621 to save the response locally, rather than process it normally (as per its media type). 622 </p> 623 <p id="rfc.section.4.2.p.2">On the other hand, if it matches "inline" (case-insensitively), this implies default processing.</p> 624 <p id="rfc.section.4.2.p.3">Unknown or unhandled disposition types <em class="bcp14">SHOULD</em> be handled by recipients the same way as "attachment" (see also <a href="#RFC2183" id="rfc.xref.RFC2183.2"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, <a href="https://tools.ietf.org/html/rfc2183#section-2.8">Section 2.8</a>). 625 </p> 626 </div> 627 <div id="disposition.parameter.filename"> 628 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a href="#disposition.parameter.filename">Disposition Parameter: 'Filename'</a></h2> 629 <p id="rfc.section.4.3.p.1">The parameters "filename" and "filename*", to be matched case-insensitively, provide information on how to construct a filename 630 for storing the message payload. 631 </p> 632 <p id="rfc.section.4.3.p.2">Depending on the disposition type, this information might be used right away (in the "save as..." interaction caused for the 633 "attachment" disposition type), or later on (for instance, when the user decides to save the contents of the current page 634 being displayed). 635 </p> 636 <p id="rfc.section.4.3.p.3">The parameters "filename" and "filename*" differ only in that "filename*" uses the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.3"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, allowing the use of characters not present in the ISO-8859-1 character set (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>). 637 </p> 638 <p id="rfc.section.4.3.p.4">Many user agent implementations predating this specification do not understand the "filename*" parameter. Therefore, when 639 both "filename" and "filename*" are present in a single header field value, recipients <em class="bcp14">SHOULD</em> pick "filename*" and ignore "filename". This way, senders can avoid special-casing specific user agents by sending both the 640 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). 641 </p> 642 <p id="rfc.section.4.3.p.5">It is essential that user agents treat the specified filename as advisory only, thus be very careful in extracting the desired 643 information. In particular: 644 </p> 645 <ul> 646 <li> 647 <p>When the value contains path separator characters ("\" or "/"), recipients <em class="bcp14">SHOULD</em> ignore all but the last path segment. This prevents unintentional overwriting of well-known file system locations (such as 648 "/etc/passwd"). 649 </p> 650 </li> 651 <li> 652 <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 653 extension could introduce a privilege escalation when the saved file is later opened (consider ".exe"). Thus, recipients need 654 to ensure that a file extension is used that is safe, optimally matching the media type of the received payload. 655 </p> 656 </li> 657 <li> 658 <p>Recipients are advised to strip or replace character sequences that are known to cause confusion both in user interfaces and 659 in filenames, such as control characters and leading and trailing whitespace. 660 </p> 661 </li> 662 <li> 663 <p>Other aspects recipients need to be aware of are names that have a special meaning in the file system or in shell commands, 664 such as "." and "..", "~", "|", and also device names. 665 </p> 666 </li> 667 </ul> 668 <div class="note" id="rfc.section.4.3.p.6"> 669 <p><b>Note:</b> Many user agents do not properly handle escape characters when using the quoted-string form. Furthermore, some user agents 670 erroneously try to perform unescaping of "percent" escapes (see <a href="#alternatives.percent" title="Percent Encoding">Appendix C.2</a>), and thus might misinterpret filenames containing the percent character followed by two hex digits. 671 </p> 672 </div> 673 </div> 674 <div id="disposition.parameter.extensions"> 675 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a href="#disposition.parameter.extensions">Disposition Parameter: Extensions</a></h2> 676 <p id="rfc.section.4.4.p.1">To enable future extensions, recipients <em class="bcp14">SHOULD</em> ignore unrecognized parameters (see also <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, <a href="https://tools.ietf.org/html/rfc2183#section-2.8">Section 2.8</a>). 677 </p> 678 </div> 679 <div id="extensibility"> 680 <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a> <a href="#extensibility">Extensibility</a></h2> 681 <p id="rfc.section.4.5.p.1">Note that <a href="https://tools.ietf.org/html/rfc2183#section-9">Section 9</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.4"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> defines IANA registries both for disposition types and disposition parameters. This registry is shared by different protocols 682 using Content-Disposition, such as MIME and HTTP. Therefore, not all registered values may make sense in the context of HTTP. 683 </p> 684 </div> 685 </div> 686 <div id="examples"> 687 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a href="#examples">Examples</a></h1> 688 <div id="rfc.figure.u.4"></div> 689 <p>Direct UA to show "save as" dialog, with a filename of "example.html":</p><pre class="text">Content-Disposition: Attachment; filename=example.html 690 </pre><div id="rfc.figure.u.5"></div> 691 <p>Direct UA to behave as if the Content-Disposition header field wasn't present, but to remember the filename "an example.html" 692 for a subsequent save operation: 693 </p><pre class="text">Content-Disposition: INLINE; FILENAME= "an example.html" 694 </pre><p>Note: this uses the quoted-string form so that the space character can be included.</p> 695 <div id="rfc.figure.u.6"></div> 696 <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; 665 697 filename*= UTF-8''<b>%e2%82%ac</b>%20rates 666 </pre> 667 </p>668 <div id="rfc.figure.u.7"></div>669 <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;698 </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. 699 </p> 700 <div id="rfc.figure.u.7"></div> 701 <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; 670 702 filename="EURO rates"; 671 703 filename*=utf-8''<b>%e2%82%ac</b>%20rates 672 </pre> <p>Note: as of February 2011, those user agents that do not support the RFC 5987 encoding ignore "filename*" when it occurs after 673 "filename". Unfortunately, some user agents that do support RFC 5987 do pick the "filename" rather than the "filename*" parameter 674 when it occurs first; it is expected that this situation is going to improve soon. 675 </p> 676 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="i18n" href="#i18n">Internationalization Considerations</a></h1> 677 <p id="rfc.section.6.p.1">The "filename*" parameter (<a href="#disposition.parameter.filename" title="Disposition Parameter: 'Filename'">Section 4.3</a>), using the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.5"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, allows the server to transmit characters outside the ISO-8859-1 character set, and also to optionally specify the language 678 in use. 679 </p> 680 <p id="rfc.section.6.p.2">Future parameters might also require internationalization, in which case the same encoding can be used.</p> 681 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 682 <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>. 683 </p> 684 <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>). 685 </p> 686 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="iana.considerations" href="#iana.considerations">IANA Considerations</a></h1> 687 <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> 688 <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 689 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>. 690 </p> 691 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 692 <p id="rfc.section.8.2.p.1">This document updates the definition of the Content-Disposition HTTP header field in the permanent HTTP header field registry 693 (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>). 694 </p> 695 <p id="rfc.section.8.2.p.2"> </p> 696 <dl> 697 <dt>Header field name:</dt> 698 <dd>Content-Disposition</dd> 699 <dt>Applicable protocol:</dt> 700 <dd>http</dd> 701 <dt>Status:</dt> 702 <dd>standard</dd> 703 <dt>Author/Change controller:</dt> 704 <dd>IETF</dd> 705 <dt>Specification document:</dt> 706 <dd>this specification (<a href="#header.field.definition" id="rfc.xref.header.field.definition.1" title="Header Field Definition">Section 4</a>) 707 </dd> 708 </dl> 709 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> Acknowledgements 710 </h1> 711 <p id="rfc.section.9.p.1">Thanks to Adam Barth, Rolf Eike Beer, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen, Henrik Nordstrom, and Mark Nottingham 712 for their valuable feedback. 713 </p> 704 </pre><p>Note: as of February 2011, those user agents that do not support the RFC 5987 encoding ignore "filename*" when it occurs after 705 "filename". Unfortunately, some user agents that do support RFC 5987 do pick the "filename" rather than the "filename*" parameter 706 when it occurs first; it is expected that this situation is going to improve soon. 707 </p> 708 </div> 709 <div id="i18n"> 710 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#i18n">Internationalization Considerations</a></h1> 711 <p id="rfc.section.6.p.1">The "filename*" parameter (<a href="#disposition.parameter.filename" title="Disposition Parameter: 'Filename'">Section 4.3</a>), using the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.5"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, allows the server to transmit characters outside the ISO-8859-1 character set, and also to optionally specify the language 712 in use. 713 </p> 714 <p id="rfc.section.6.p.2">Future parameters might also require internationalization, in which case the same encoding can be used.</p> 715 </div> 716 <div id="security.considerations"> 717 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#security.considerations">Security Considerations</a></h1> 718 <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>. 719 </p> 720 <p id="rfc.section.7.p.2">Furthermore, implementers also ought to be aware of the Security Considerations applying to HTTP (see <a href="https://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="https://tools.ietf.org/html/rfc5987#section-5" id="rfc.xref.RFC5987.7">Section 5</a>). 721 </p> 722 </div> 723 <div id="iana.considerations"> 724 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a href="#iana.considerations">IANA Considerations</a></h1> 725 <div id="registry"> 726 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a href="#registry">Registry for Disposition Values and Parameter</a></h2> 727 <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 728 are defined in <a href="https://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>. 729 </p> 730 </div> 731 <div id="header.field.registration"> 732 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a href="#header.field.registration">Header Field Registration</a></h2> 733 <p id="rfc.section.8.2.p.1">This document updates the definition of the Content-Disposition HTTP header field in the permanent HTTP header field registry 734 (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>). 735 </p> 736 <p id="rfc.section.8.2.p.2"></p> 737 <dl> 738 <dt>Header field name:</dt> 739 <dd>Content-Disposition</dd> 740 <dt>Applicable protocol:</dt> 741 <dd>http</dd> 742 <dt>Status:</dt> 743 <dd>standard</dd> 744 <dt>Author/Change controller:</dt> 745 <dd>IETF</dd> 746 <dt>Specification document:</dt> 747 <dd>this specification (<a href="#header.field.definition" id="rfc.xref.header.field.definition.1" title="Header Field Definition">Section 4</a>) 748 </dd> 749 </dl> 750 </div> 751 </div> 752 <div> 753 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> Acknowledgements 754 </h1> 755 <p id="rfc.section.9.p.1">Thanks to Adam Barth, Rolf Eike Beer, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen, Henrik Nordstrom, and Mark Nottingham 756 for their valuable feedback. 757 </p> 758 </div> 714 759 <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References 715 760 </h1> 716 761 <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References 717 762 </h2> 718 <table> 763 <table> 719 764 <tr> 720 765 <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td> … … 723 768 <tr> 724 769 <td class="reference"><b id="RFC2119">[RFC2119]</b></td> 725 <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http ://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP 14, RFC 2119, March 1997.770 <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP 14, RFC 2119, March 1997. 726 771 </td> 727 772 </tr> 728 773 <tr> 729 774 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 730 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http ://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999.775 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. 731 776 </td> 732 777 </tr> 733 778 <tr> 734 779 <td class="reference"><b id="RFC5987">[RFC5987]</b></td> 735 <td class="top"><a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J.</a>, “<a href="http ://tools.ietf.org/html/rfc5987">Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</a>”, RFC 5987, August 2010.780 <td class="top"><a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J.</a>, “<a href="https://tools.ietf.org/html/rfc5987">Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</a>”, RFC 5987, August 2010. 736 781 </td> 737 782 </tr> … … 739 784 <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References 740 785 </h2> 741 <table> 786 <table> 742 787 <tr> 743 788 <td class="reference"><b id="RFC2046">[RFC2046]</b></td> 744 <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http ://tools.ietf.org/html/rfc2046">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>”, RFC 2046, November 1996.789 <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="https://tools.ietf.org/html/rfc2046">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>”, RFC 2046, November 1996. 745 790 </td> 746 791 </tr> 747 792 <tr> 748 793 <td class="reference"><b id="RFC2047">[RFC2047]</b></td> 749 <td class="top"><a href="mailto:moore@cs.utk.edu" title="University of Tennessee">Moore, K.</a>, “<a href="http ://tools.ietf.org/html/rfc2047">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</a>”, RFC 2047, November 1996.794 <td class="top"><a href="mailto:moore@cs.utk.edu" title="University of Tennessee">Moore, K.</a>, “<a href="https://tools.ietf.org/html/rfc2047">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</a>”, RFC 2047, November 1996. 750 795 </td> 751 796 </tr> 752 797 <tr> 753 798 <td class="reference"><b id="RFC2183">[RFC2183]</b></td> 754 <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.799 <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="https://tools.ietf.org/html/rfc2183">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a>”, RFC 2183, August 1997. 755 800 </td> 756 801 </tr> 757 802 <tr> 758 803 <td class="reference"><b id="RFC2231">[RFC2231]</b></td> 759 <td class="top"><a href="mailto:ned.freed@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:moore@cs.utk.edu" title="University of Tennessee">K. Moore</a>, “<a href="http ://tools.ietf.org/html/rfc2231">MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</a>”, RFC 2231, November 1997.804 <td class="top"><a href="mailto:ned.freed@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:moore@cs.utk.edu" title="University of Tennessee">K. Moore</a>, “<a href="https://tools.ietf.org/html/rfc2231">MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</a>”, RFC 2231, November 1997. 760 805 </td> 761 806 </tr> 762 807 <tr> 763 808 <td class="reference"><b id="RFC2388">[RFC2388]</b></td> 764 <td class="top"><a href="mailto:masinter@parc.xerox.com" title="Xerox Palo Alto Research Center">Masinter, L.</a>, “<a href="http ://tools.ietf.org/html/rfc2388">Returning Values from Forms: multipart/form-data</a>”, RFC 2388, August 1998.809 <td class="top"><a href="mailto:masinter@parc.xerox.com" title="Xerox Palo Alto Research Center">Masinter, L.</a>, “<a href="https://tools.ietf.org/html/rfc2388">Returning Values from Forms: multipart/form-data</a>”, RFC 2388, August 1998. 765 810 </td> 766 811 </tr> 767 812 <tr> 768 813 <td class="reference"><b id="RFC3864">[RFC3864]</b></td> 769 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http ://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004.814 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="https://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. 770 815 </td> 771 816 </tr> 772 817 <tr> 773 818 <td class="reference"><b id="RFC3986">[RFC3986]</b></td> 774 <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="http ://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD 66, RFC 3986, January 2005.819 <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="https://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD 66, RFC 3986, January 2005. 775 820 </td> 776 821 </tr> 777 822 </table> 778 <div class="avoidbreak"> 779 <h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1> 780 <address class="vcard"><span class="vcardline"><span class="fn">Julian F. Reschke</span><span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span> <span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de"><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address> 781 </div> 782 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="changes.from.rfc2616" href="#changes.from.rfc2616">Changes from the RFC 2616 Definition</a></h1> 783 <p id="rfc.section.A.p.1">Compared to <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.10"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, the following normative changes reflecting actual implementations have been made: 784 </p> 785 <ul> 786 <li>According to RFC 2616, the disposition type "attachment" only applies to content of type "application/octet-stream". This 787 restriction has been removed, because user agents in practice do not check the content type, and it also discourages properly 788 declaring the media type. 789 </li> 790 <li>RFC 2616 only allows "quoted-string" for the filename parameter. This would be an exceptional parameter syntax, and also doesn't 791 reflect actual use. 792 </li> 793 <li>The definition for the disposition type "inline" (<a href="#RFC2183" id="rfc.xref.RFC2183.6"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, <a href="http://tools.ietf.org/html/rfc2183#section-2.1">Section 2.1</a>) has been re-added with a suggestion for its processing. 794 </li> 795 <li>This specification requires support for the extended parameter encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.8"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>. 796 </li> 797 </ul> 798 <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> 799 <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 800 majority of user agents does not implement these, thus they have been omitted from this specification. 801 </p> 802 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="alternatives" href="#alternatives">Alternative Approaches to Internationalization</a></h1> 803 <p id="rfc.section.C.p.1">By default, HTTP header field parameters cannot carry characters outside the ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.2"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) character encoding (see <a href="#RFC2616" id="rfc.xref.RFC2616.11"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a>). For the "filename" parameter, this of course is an unacceptable restriction. 804 </p> 805 <p id="rfc.section.C.p.2">Unfortunately, user agent implementers have not managed to come up with an interoperable approach, although the IETF Standards 806 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>). 807 </p> 808 <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 809 to the RFC 5987 encoding used in this specification. 810 </p> 811 <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> 812 <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 813 - 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>: 814 </p> 815 <blockquote id="rfc.section.C.1.p.2" cite="http://tools.ietf.org/html/rfc2047#section-5"> 816 <p>An 'encoded-word' MUST NOT appear within a 'quoted-string'.</p> 817 <p>...</p> 818 <p>An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured 819 field body except within a 'comment' or 'phrase'. 820 </p> 821 </blockquote> 822 <p id="rfc.section.C.1.p.3">In practice, some user agents implement the encoding, some do not (exposing the encoded string to the user), and some get 823 confused by it. 824 </p> 825 <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> 826 <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 827 of the referring page, the user agent's locale, its configuration, and also the actual value of the parameter. 828 </p> 829 <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 830 to the user. For those user agents that do implement this it is difficult to predict what character encoding they actually 831 expect. 832 </p> 833 <h2 id="rfc.section.C.3"><a href="#rfc.section.C.3">C.3</a> <a id="alternatives.sniff" href="#alternatives.sniff">Encoding Sniffing</a></h2> 834 <p id="rfc.section.C.3.p.1">Some user agents inspect the value (which defaults to ISO-8859-1 for the quoted-string form) and switch to UTF-8 when it seems 835 to be more likely to be the correct interpretation. 836 </p> 837 <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> 838 <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> 839 <p id="rfc.section.C.4.p.1">Unfortunately, as of February 2011, neither the encoding defined in RFCs 2231 and 5987, nor any of the alternate approaches 840 discussed above was implemented interoperably. Thus, this specification recommends the approach defined in RFC 5987, which 841 at least has the advantage of actually being specified properly. 842 </p> 843 <p id="rfc.section.C.4.p.2">The table below shows the implementation support for the various approaches:</p> 844 <div id="rfc.table.u.1"> 845 <table class="tt full left" cellpadding="3" cellspacing="0"> 846 <thead> 847 <tr> 848 <th>User Agent</th> 849 <th>RFC 2231/5987</th> 850 <th>RFC 2047</th> 851 <th>Percent Encoding</th> 852 <th>Encoding Sniffing</th> 853 </tr> 854 </thead> 855 <tbody> 856 <tr> 857 <td class="left">Chrome</td> 858 <td class="left">yes</td> 859 <td class="left">yes</td> 860 <td class="left">yes</td> 861 <td class="left">yes</td> 862 </tr> 863 <tr> 864 <td class="left">Firefox</td> 865 <td class="left">yes (*)</td> 866 <td class="left">yes</td> 867 <td class="left">no</td> 868 <td class="left">yes</td> 869 </tr> 870 <tr> 871 <td class="left">Internet Explorer</td> 872 <td class="left">yes (**)</td> 873 <td class="left">no</td> 874 <td class="left">yes</td> 875 <td class="left">no</td> 876 </tr> 877 <tr> 878 <td class="left">Konqueror</td> 879 <td class="left">yes</td> 880 <td class="left">no</td> 881 <td class="left">no</td> 882 <td class="left">no</td> 883 </tr> 884 <tr> 885 <td class="left">Opera</td> 886 <td class="left">yes</td> 887 <td class="left">no</td> 888 <td class="left">no</td> 889 <td class="left">no</td> 890 </tr> 891 <tr> 892 <td class="left">Safari</td> 893 <td class="left">no</td> 894 <td class="left">no</td> 895 <td class="left">no</td> 896 <td class="left">yes</td> 897 </tr> 898 </tbody> 899 </table> 900 </div> 901 <p id="rfc.section.C.4.p.3">(*) Does not implement the fallback behavior to "filename" described in <a href="#disposition.parameter.filename" title="Disposition Parameter: 'Filename'">Section 4.3</a>. 902 </p> 903 <p id="rfc.section.C.4.p.4">(**) Starting with IE9RC, but only implements UTF-8.</p> 904 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> 905 <p id="rfc.section.D.p.1">Note: the issues names in the change log entries for draft-reschke-rfc2183-in-http refer to <<a href="http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-issues.html">http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-issues.html</a>>. 906 </p> 907 <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a> Since draft-reschke-rfc2183-in-http-00 908 </h2> 909 <p id="rfc.section.D.1.p.1">Adjust terminology ("header" -> "header field"). Update rfc2231-in-http reference.</p> 910 <h2 id="rfc.section.D.2"><a href="#rfc.section.D.2">D.2</a> Since draft-reschke-rfc2183-in-http-01 911 </h2> 912 <p id="rfc.section.D.2.p.1">Update rfc2231-in-http reference. Actually define the "filename" parameter. Add internationalization considerations. Add examples 913 using the RFC 5987 encoding. Add overview over other approaches, plus a table reporting implementation status. Add and resolve 914 issue "nodep2183". Add issues "asciivsiso", "deplboth", "quoted", and "registry". 915 </p> 916 <h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a> Since draft-reschke-rfc2183-in-http-02 917 </h2> 918 <p id="rfc.section.D.3.p.1">Add and close issue "docfallback". Close issues "asciivsiso", "deplboth", "quoted", and "registry".</p> 919 <h2 id="rfc.section.D.4"><a href="#rfc.section.D.4">D.4</a> Since draft-reschke-rfc2183-in-http-03 920 </h2> 921 <p id="rfc.section.D.4.p.1">Updated to be a Working Draft of the IETF HTTPbis Working Group.</p> 922 <h2 id="rfc.section.D.5"><a href="#rfc.section.D.5">D.5</a> <a id="changes.since.00" href="#changes.since.00">Since draft-ietf-httpbis-content-disp-00</a></h2> 923 <p id="rfc.section.D.5.p.1">Closed issues: </p> 924 <ul> 925 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/242">http://tools.ietf.org/wg/httpbis/trac/ticket/242</a>>: "handling of unknown disposition types" 926 </li> 927 </ul> 928 <p id="rfc.section.D.5.p.2">Slightly updated the notes about the proposed fallback behavior.</p> 929 <h2 id="rfc.section.D.6"><a href="#rfc.section.D.6">D.6</a> <a id="changes.since.01" href="#changes.since.01">Since draft-ietf-httpbis-content-disp-01</a></h2> 930 <p id="rfc.section.D.6.p.1">Various editorial improvements.</p> 931 <h2 id="rfc.section.D.7"><a href="#rfc.section.D.7">D.7</a> <a id="changes.since.02" href="#changes.since.02">Since draft-ietf-httpbis-content-disp-02</a></h2> 932 <p id="rfc.section.D.7.p.1">Closed issues: </p> 933 <ul> 934 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/244">http://tools.ietf.org/wg/httpbis/trac/ticket/244</a>>: "state that repeating parameters are invalid" 935 </li> 936 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/245">http://tools.ietf.org/wg/httpbis/trac/ticket/245</a>>: "warn about %xx in filenames being misinterpreted" 937 </li> 938 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/246">http://tools.ietf.org/wg/httpbis/trac/ticket/246</a>>: "mention control chars when talking about postprecessing the filename parameter" 939 </li> 940 </ul> 941 <p id="rfc.section.D.7.p.2">Update <a href="#alternatives.implementations" title="Implementations (to be removed by RFC Editor before publication)">Appendix C.4</a>; Opera 10.63 RC implements the recommended fallback behavior. 942 </p> 943 <h2 id="rfc.section.D.8"><a href="#rfc.section.D.8">D.8</a> <a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-content-disp-03</a></h2> 944 <p id="rfc.section.D.8.p.1">Closed issues: </p> 945 <ul> 946 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/252">http://tools.ietf.org/wg/httpbis/trac/ticket/252</a>>: "'modification-date' *is* implemented in Konq 4.5" 947 </li> 948 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/253">http://tools.ietf.org/wg/httpbis/trac/ticket/253</a>>: "clarify what LWS means for the Content-Disp grammar" 949 </li> 950 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/258">http://tools.ietf.org/wg/httpbis/trac/ticket/258</a>>: "Avoid passive voice in message requirements" 951 </li> 952 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/263">http://tools.ietf.org/wg/httpbis/trac/ticket/263</a>>: "text about historical percent-decoding unclear" 953 </li> 954 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/264">http://tools.ietf.org/wg/httpbis/trac/ticket/264</a>>: "add explanation of language tagging" 955 </li> 956 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/265">http://tools.ietf.org/wg/httpbis/trac/ticket/265</a>>: "Clarify that C-D spec does not apply to multipart upload" 957 </li> 958 </ul> 959 <h2 id="rfc.section.D.9"><a href="#rfc.section.D.9">D.9</a> <a id="changes.since.04" href="#changes.since.04">Since draft-ietf-httpbis-content-disp-04</a></h2> 960 <p id="rfc.section.D.9.p.1">Updated implementation information (Chrome 9 implements RFC 5987, IE 9 RC implements it for UTF-8 only).</p> 961 <p id="rfc.section.D.9.p.2">Clarify who requirements are on, add a section discussing conformance and handling of invalid field values in general.</p> 962 <p id="rfc.section.D.9.p.3">Closed issues: </p> 963 <ul> 964 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/272">http://tools.ietf.org/wg/httpbis/trac/ticket/272</a>>: "Path Separator Characters" 965 </li> 966 </ul> 823 <div id="changes.from.rfc2616"> 824 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a href="#changes.from.rfc2616">Changes from the RFC 2616 Definition</a></h1> 825 <p id="rfc.section.A.p.1">Compared to <a href="https://tools.ietf.org/html/rfc2616#section-19.5.1">Section 19.5.1</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.10"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, the following normative changes reflecting actual implementations have been made: 826 </p> 827 <ul> 828 <li>According to RFC 2616, the disposition type "attachment" only applies to content of type "application/octet-stream". This 829 restriction has been removed, because user agents in practice do not check the content type, and it also discourages properly 830 declaring the media type. 831 </li> 832 <li>RFC 2616 only allows "quoted-string" for the filename parameter. This would be an exceptional parameter syntax, and also doesn't 833 reflect actual use. 834 </li> 835 <li>The definition for the disposition type "inline" (<a href="#RFC2183" id="rfc.xref.RFC2183.6"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, <a href="https://tools.ietf.org/html/rfc2183#section-2.1">Section 2.1</a>) has been re-added with a suggestion for its processing. 836 </li> 837 <li>This specification requires support for the extended parameter encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.8"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>. 838 </li> 839 </ul> 840 </div> 841 <div id="diffs.compared.to.rfc2183"> 842 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a href="#diffs.compared.to.rfc2183">Differences compared to RFC 2183</a></h1> 843 <p id="rfc.section.B.p.1"><a href="https://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 844 majority of user agents does not implement these, thus they have been omitted from this specification. 845 </p> 846 </div> 847 <div id="alternatives"> 848 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a href="#alternatives">Alternative Approaches to Internationalization</a></h1> 849 <p id="rfc.section.C.p.1">By default, HTTP header field parameters cannot carry characters outside the ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.2"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) character encoding (see <a href="#RFC2616" id="rfc.xref.RFC2616.11"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="https://tools.ietf.org/html/rfc2616#section-2.2">Section 2.2</a>). For the "filename" parameter, this of course is an unacceptable restriction. 850 </p> 851 <p id="rfc.section.C.p.2">Unfortunately, user agent implementers have not managed to come up with an interoperable approach, although the IETF Standards 852 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>). 853 </p> 854 <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 855 to the RFC 5987 encoding used in this specification. 856 </p> 857 <div id="alternatives.rfc2047"> 858 <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a> <a href="#alternatives.rfc2047">RFC 2047 Encoding</a></h2> 859 <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 860 - see <a href="https://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>: 861 </p> 862 <blockquote id="rfc.section.C.1.p.2" cite="http://tools.ietf.org/html/rfc2047#section-5"> 863 <p>An 'encoded-word' MUST NOT appear within a 'quoted-string'.</p> 864 <p>...</p> 865 <p>An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured 866 field body except within a 'comment' or 'phrase'. 867 </p> 868 </blockquote> 869 <p id="rfc.section.C.1.p.3">In practice, some user agents implement the encoding, some do not (exposing the encoded string to the user), and some get 870 confused by it. 871 </p> 872 </div> 873 <div id="alternatives.percent"> 874 <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a> <a href="#alternatives.percent">Percent Encoding</a></h2> 875 <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="https://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 876 of the referring page, the user agent's locale, its configuration, and also the actual value of the parameter. 877 </p> 878 <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 879 to the user. For those user agents that do implement this it is difficult to predict what character encoding they actually 880 expect. 881 </p> 882 </div> 883 <div id="alternatives.sniff"> 884 <h2 id="rfc.section.C.3"><a href="#rfc.section.C.3">C.3</a> <a href="#alternatives.sniff">Encoding Sniffing</a></h2> 885 <p id="rfc.section.C.3.p.1">Some user agents inspect the value (which defaults to ISO-8859-1 for the quoted-string form) and switch to UTF-8 when it seems 886 to be more likely to be the correct interpretation. 887 </p> 888 <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> 889 </div> 890 <div id="alternatives.implementations"> 891 <h2 id="rfc.section.C.4"><a href="#rfc.section.C.4">C.4</a> <a href="#alternatives.implementations">Implementations (to be removed by RFC Editor before publication)</a></h2> 892 <p id="rfc.section.C.4.p.1">Unfortunately, as of February 2011, neither the encoding defined in RFCs 2231 and 5987, nor any of the alternate approaches 893 discussed above was implemented interoperably. Thus, this specification recommends the approach defined in RFC 5987, which 894 at least has the advantage of actually being specified properly. 895 </p> 896 <p id="rfc.section.C.4.p.2">The table below shows the implementation support for the various approaches:</p> 897 <div id="rfc.table.u.1"> 898 <table class="tt full left" cellpadding="3" cellspacing="0"> 899 <thead> 900 <tr> 901 <th>User Agent</th> 902 <th>RFC 2231/5987</th> 903 <th>RFC 2047</th> 904 <th>Percent Encoding</th> 905 <th>Encoding Sniffing</th> 906 </tr> 907 </thead> 908 <tbody> 909 <tr> 910 <td class="left">Chrome</td> 911 <td class="left">yes</td> 912 <td class="left">yes</td> 913 <td class="left">yes</td> 914 <td class="left">yes</td> 915 </tr> 916 <tr> 917 <td class="left">Firefox</td> 918 <td class="left">yes (*)</td> 919 <td class="left">yes</td> 920 <td class="left">no</td> 921 <td class="left">yes</td> 922 </tr> 923 <tr> 924 <td class="left">Internet Explorer</td> 925 <td class="left">yes (**)</td> 926 <td class="left">no</td> 927 <td class="left">yes</td> 928 <td class="left">no</td> 929 </tr> 930 <tr> 931 <td class="left">Konqueror</td> 932 <td class="left">yes</td> 933 <td class="left">no</td> 934 <td class="left">no</td> 935 <td class="left">no</td> 936 </tr> 937 <tr> 938 <td class="left">Opera</td> 939 <td class="left">yes</td> 940 <td class="left">no</td> 941 <td class="left">no</td> 942 <td class="left">no</td> 943 </tr> 944 <tr> 945 <td class="left">Safari</td> 946 <td class="left">no</td> 947 <td class="left">no</td> 948 <td class="left">no</td> 949 <td class="left">yes</td> 950 </tr> 951 </tbody> 952 </table> 953 </div> 954 <p id="rfc.section.C.4.p.3">(*) Does not implement the fallback behavior to "filename" described in <a href="#disposition.parameter.filename" title="Disposition Parameter: 'Filename'">Section 4.3</a>. 955 </p> 956 <p id="rfc.section.C.4.p.4">(**) Starting with IE9RC, but only implements UTF-8.</p> 957 </div> 958 </div> 959 <div id="change.log"> 960 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> 961 <p id="rfc.section.D.p.1">Note: the issues names in the change log entries for draft-reschke-rfc2183-in-http refer to <<a href="http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-issues.html">http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-issues.html</a>>. 962 </p> 963 <div> 964 <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a> Since draft-reschke-rfc2183-in-http-00 965 </h2> 966 <p id="rfc.section.D.1.p.1">Adjust terminology ("header" -> "header field"). Update rfc2231-in-http reference.</p> 967 </div> 968 <div> 969 <h2 id="rfc.section.D.2"><a href="#rfc.section.D.2">D.2</a> Since draft-reschke-rfc2183-in-http-01 970 </h2> 971 <p id="rfc.section.D.2.p.1">Update rfc2231-in-http reference. Actually define the "filename" parameter. Add internationalization considerations. Add examples 972 using the RFC 5987 encoding. Add overview over other approaches, plus a table reporting implementation status. Add and resolve 973 issue "nodep2183". Add issues "asciivsiso", "deplboth", "quoted", and "registry". 974 </p> 975 </div> 976 <div> 977 <h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a> Since draft-reschke-rfc2183-in-http-02 978 </h2> 979 <p id="rfc.section.D.3.p.1">Add and close issue "docfallback". Close issues "asciivsiso", "deplboth", "quoted", and "registry".</p> 980 </div> 981 <div> 982 <h2 id="rfc.section.D.4"><a href="#rfc.section.D.4">D.4</a> Since draft-reschke-rfc2183-in-http-03 983 </h2> 984 <p id="rfc.section.D.4.p.1">Updated to be a Working Draft of the IETF HTTPbis Working Group.</p> 985 </div> 986 <div id="changes.since.00"> 987 <h2 id="rfc.section.D.5"><a href="#rfc.section.D.5">D.5</a> <a href="#changes.since.00">Since draft-ietf-httpbis-content-disp-00</a></h2> 988 <p id="rfc.section.D.5.p.1">Closed issues: </p> 989 <ul> 990 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/242">http://tools.ietf.org/wg/httpbis/trac/ticket/242</a>>: "handling of unknown disposition types" 991 </li> 992 </ul> 993 <p id="rfc.section.D.5.p.2">Slightly updated the notes about the proposed fallback behavior.</p> 994 </div> 995 <div id="changes.since.01"> 996 <h2 id="rfc.section.D.6"><a href="#rfc.section.D.6">D.6</a> <a href="#changes.since.01">Since draft-ietf-httpbis-content-disp-01</a></h2> 997 <p id="rfc.section.D.6.p.1">Various editorial improvements.</p> 998 </div> 999 <div id="changes.since.02"> 1000 <h2 id="rfc.section.D.7"><a href="#rfc.section.D.7">D.7</a> <a href="#changes.since.02">Since draft-ietf-httpbis-content-disp-02</a></h2> 1001 <p id="rfc.section.D.7.p.1">Closed issues: </p> 1002 <ul> 1003 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/244">http://tools.ietf.org/wg/httpbis/trac/ticket/244</a>>: "state that repeating parameters are invalid" 1004 </li> 1005 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/245">http://tools.ietf.org/wg/httpbis/trac/ticket/245</a>>: "warn about %xx in filenames being misinterpreted" 1006 </li> 1007 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/246">http://tools.ietf.org/wg/httpbis/trac/ticket/246</a>>: "mention control chars when talking about postprecessing the filename parameter" 1008 </li> 1009 </ul> 1010 <p id="rfc.section.D.7.p.2">Update <a href="#alternatives.implementations" title="Implementations (to be removed by RFC Editor before publication)">Appendix C.4</a>; Opera 10.63 RC implements the recommended fallback behavior. 1011 </p> 1012 </div> 1013 <div id="changes.since.03"> 1014 <h2 id="rfc.section.D.8"><a href="#rfc.section.D.8">D.8</a> <a href="#changes.since.03">Since draft-ietf-httpbis-content-disp-03</a></h2> 1015 <p id="rfc.section.D.8.p.1">Closed issues: </p> 1016 <ul> 1017 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/252">http://tools.ietf.org/wg/httpbis/trac/ticket/252</a>>: "'modification-date' *is* implemented in Konq 4.5" 1018 </li> 1019 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/253">http://tools.ietf.org/wg/httpbis/trac/ticket/253</a>>: "clarify what LWS means for the Content-Disp grammar" 1020 </li> 1021 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/258">http://tools.ietf.org/wg/httpbis/trac/ticket/258</a>>: "Avoid passive voice in message requirements" 1022 </li> 1023 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/263">http://tools.ietf.org/wg/httpbis/trac/ticket/263</a>>: "text about historical percent-decoding unclear" 1024 </li> 1025 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/264">http://tools.ietf.org/wg/httpbis/trac/ticket/264</a>>: "add explanation of language tagging" 1026 </li> 1027 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/265">http://tools.ietf.org/wg/httpbis/trac/ticket/265</a>>: "Clarify that C-D spec does not apply to multipart upload" 1028 </li> 1029 </ul> 1030 </div> 1031 <div id="changes.since.04"> 1032 <h2 id="rfc.section.D.9"><a href="#rfc.section.D.9">D.9</a> <a href="#changes.since.04">Since draft-ietf-httpbis-content-disp-04</a></h2> 1033 <p id="rfc.section.D.9.p.1">Updated implementation information (Chrome 9 implements RFC 5987, IE 9 RC implements it for UTF-8 only).</p> 1034 <p id="rfc.section.D.9.p.2">Clarify who requirements are on, add a section discussing conformance and handling of invalid field values in general.</p> 1035 <p id="rfc.section.D.9.p.3">Closed issues: </p> 1036 <ul> 1037 <li><<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/272">http://tools.ietf.org/wg/httpbis/trac/ticket/272</a>>: "Path Separator Characters" 1038 </li> 1039 </ul> 1040 </div> 1041 </div> 967 1042 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 968 1043 <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> … … 1025 1100 </ul> 1026 1101 </div> 1102 <div class="avoidbreak"> 1103 <h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1> 1104 <p><b>Julian F. Reschke</b><br>greenbytes GmbH<br>Hafenweg 16<br>Muenster, NW 48155<br>Germany<br>Email: <a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a><br>URI: <a href="http://greenbytes.de/tech/webdav/">http://greenbytes.de/tech/webdav/</a></p> 1105 </div> 1027 1106 </body> 1028 1107 </html>
Note: See TracChangeset
for help on using the changeset viewer.