idnits 2.17.1 draft-ietf-httpbis-content-disp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2616, but the abstract doesn't seem to directly say this. It does mention RFC2616 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2616, updated by this document, for RFC5378 checks: 1997-10-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 14, 2011) is 4790 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859-1' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5987 (Obsoleted by RFC 8187) -- Obsolete informational reference (is this intentional?): RFC 2388 (Obsoleted by RFC 7578) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group J. Reschke 3 Internet-Draft greenbytes 4 Updates: 2616 (if approved) March 14, 2011 5 Intended status: Standards Track 6 Expires: September 15, 2011 8 Use of the Content-Disposition Header Field in the 9 Hypertext Transfer Protocol (HTTP) 10 draft-ietf-httpbis-content-disp-07 12 Abstract 14 RFC 2616 defines the Content-Disposition response header field, but 15 points out that it is not part of the HTTP/1.1 Standard. This 16 specification takes over the definition and registration of Content- 17 Disposition, as used in HTTP, and clarifies internationalization 18 aspects. 20 Editorial Note (To be removed by RFC Editor before publication) 22 This specification is expected to replace the definition of Content- 23 Disposition in the HTTP/1.1 specification, as currently revised by 24 the IETF HTTPbis working group. See also 25 . 27 Discussion of this draft should take place on the HTTPBIS working 28 group mailing list (ietf-http-wg@w3.org). The current issues list is 29 at and related documents (including fancy 31 diffs) can be found at . 33 The changes in this draft are summarized in Appendix E.11. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 15, 2011. 51 Copyright Notice 53 Copyright (c) 2011 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 70 3. Conformance and Error Handling . . . . . . . . . . . . . . . . 4 71 4. Header Field Definition . . . . . . . . . . . . . . . . . . . 5 72 4.1. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.2. Disposition Type . . . . . . . . . . . . . . . . . . . . . 6 74 4.3. Disposition Parameter: 'Filename' . . . . . . . . . . . . 6 75 4.4. Disposition Parameter: Extensions . . . . . . . . . . . . 7 76 4.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 7 77 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 6. Internationalization Considerations . . . . . . . . . . . . . 8 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 8.1. Registry for Disposition Values and Parameter . . . . . . 9 82 8.2. Header Field Registration . . . . . . . . . . . . . . . . 9 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 86 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 87 Appendix A. Changes from the RFC 2616 Definition . . . . . . . . 10 88 Appendix B. Differences compared to RFC 2183 . . . . . . . . . . 11 89 Appendix C. Alternative Approaches to Internationalization . . . 11 90 C.1. RFC 2047 Encoding . . . . . . . . . . . . . . . . . . . . 11 91 C.2. Percent Encoding . . . . . . . . . . . . . . . . . . . . . 12 92 C.3. Encoding Sniffing . . . . . . . . . . . . . . . . . . . . 12 93 C.4. Implementations (to be removed by RFC Editor before 94 publication) . . . . . . . . . . . . . . . . . . . . . . . 12 95 Appendix D. Advice on Generating Content-Disposition Header 96 Fields . . . . . . . . . . . . . . . . . . . . . . . 13 97 Appendix E. Change Log (to be removed by RFC Editor before 98 publication) . . . . . . . . . . . . . . . . . . . . 14 99 E.1. Since draft-reschke-rfc2183-in-http-00 . . . . . . . . . . 14 100 E.2. Since draft-reschke-rfc2183-in-http-01 . . . . . . . . . . 14 101 E.3. Since draft-reschke-rfc2183-in-http-02 . . . . . . . . . . 14 102 E.4. Since draft-reschke-rfc2183-in-http-03 . . . . . . . . . . 15 103 E.5. Since draft-ietf-httpbis-content-disp-00 . . . . . . . . . 15 104 E.6. Since draft-ietf-httpbis-content-disp-01 . . . . . . . . . 15 105 E.7. Since draft-ietf-httpbis-content-disp-02 . . . . . . . . . 15 106 E.8. Since draft-ietf-httpbis-content-disp-03 . . . . . . . . . 15 107 E.9. Since draft-ietf-httpbis-content-disp-04 . . . . . . . . . 16 108 E.10. Since draft-ietf-httpbis-content-disp-05 . . . . . . . . . 16 109 E.11. Since draft-ietf-httpbis-content-disp-06 . . . . . . . . . 16 110 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 112 1. Introduction 114 RFC 2616 defines the Content-Disposition response header field in 115 Section 19.5.1 of [RFC2616], but points out that it is not part of 116 the HTTP/1.1 Standard (Section 15.5): 118 Content-Disposition is not part of the HTTP standard, but since it 119 is widely implemented, we are documenting its use and risks for 120 implementers. 122 This specification takes over the definition and registration of 123 Content-Disposition, as used in HTTP. Based on interoperability 124 testing with existing User Agents, it fully defines a profile of the 125 features defined in the Multipurpose Internet Mail Extensions (MIME) 126 variant ([RFC2183]) of the header field, and also clarifies 127 internationalization aspects. 129 Note: this document does not apply to Content-Disposition header 130 fields appearing in payload bodies transmitted over HTTP, such as 131 when using the media type "multipart/form-data" ([RFC2388]). 133 2. Notational Conventions 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 This specification uses the augmented BNF notation defined in Section 140 2.1 of [RFC2616], including its rules for implied linear whitespace 141 (LWS). 143 3. Conformance and Error Handling 145 This specification defines conformance criteria for both senders 146 (usually, HTTP origin servers) and recipients (usually, HTTP user 147 agents) of the Content-Disposition header field. An implementation 148 is considered conformant if it complies with all of the requirements 149 associated with its role. 151 This specification also defines certain forms of the header field- 152 value to be invalid, using both ABNF and prose requirements, but it 153 does not define special handling of these invalid field-values. 155 Senders MUST NOT generate Content-Disposition header fields that are 156 invalid. 158 Recipients MAY take steps to recover a usable field-value from an 159 invalid header field, but SHOULD NOT reject the message outright, 160 unless this is explicitly desirable behaviour (e.g., the 161 implementation is a validator). As such, the default handling of 162 invalid fields is to ignore them. 164 4. Header Field Definition 166 The Content-Disposition response header field is used to convey 167 additional information about how to process the response payload, and 168 also can be used to attach additional metadata, such as the filename 169 to use when saving the response payload locally. 171 4.1. Grammar 173 content-disposition = "Content-Disposition" ":" 174 disposition-type *( ";" disposition-parm ) 176 disposition-type = "inline" | "attachment" | disp-ext-type 177 ; case-insensitive 178 disp-ext-type = token 180 disposition-parm = filename-parm | disp-ext-parm 182 filename-parm = "filename" "=" value 183 | "filename*" "=" ext-value 185 disp-ext-parm = token "=" value 186 | ext-token "=" ext-value 187 ext-token = 189 Defined in [RFC2616]: 191 token = 192 quoted-string = 193 value = 194 ; token | quoted-string 196 Defined in [RFC5987]: 198 ext-value = 200 Header field values with multiple instances of the same parameter 201 name are invalid. 203 Note that due to the rules for implied linear whitespace (Section 2.1 204 of [RFC2616]), OPTIONAL whitespace can appear between words (token or 205 quoted-string) and separator characters. 207 Furthermore note that the format used for ext-value allows specifying 208 a natural language; this is of limited use for filenames and is 209 likely to be ignored by recipients. 211 4.2. Disposition Type 213 If the disposition type matches "attachment" (case-insensitively), 214 this indicates that the recipient should prompt the user to save the 215 response locally, rather than process it normally (as per its media 216 type). 218 On the other hand, if it matches "inline" (case-insensitively), this 219 implies default processing. Therefore, the disposition type "inline" 220 is only useful when it is augmented with additional parameters, such 221 as the filename (see below). 223 Unknown or unhandled disposition types SHOULD be handled by 224 recipients the same way as "attachment" (see also [RFC2183], Section 225 2.8). 227 4.3. Disposition Parameter: 'Filename' 229 The parameters "filename" and "filename*", to be matched case- 230 insensitively, provide information on how to construct a filename for 231 storing the message payload. 233 Depending on the disposition type, this information might be used 234 right away (in the "save as..." interaction caused for the 235 "attachment" disposition type), or later on (for instance, when the 236 user decides to save the contents of the current page being 237 displayed). 239 The parameters "filename" and "filename*" differ only in that 240 "filename*" uses the encoding defined in [RFC5987], allowing the use 241 of characters not present in the ISO-8859-1 character set 242 ([ISO-8859-1]). 244 Many user agent implementations predating this specification do not 245 understand the "filename*" parameter. Therefore, when both 246 "filename" and "filename*" are present in a single header field 247 value, recipients SHOULD pick "filename*" and ignore "filename". 248 This way, senders can avoid special-casing specific user agents by 249 sending both the more expressive "filename*" parameter, and the 250 "filename" parameter as fallback for legacy recipients (see Section 5 251 for an example). 253 It is essential that recipients treat the specified filename as 254 advisory only, thus be very careful in extracting the desired 255 information. In particular: 257 o When the value contains path separator characters ("\" or "/"), 258 recipients SHOULD ignore all but the last path segment. This 259 prevents unintentional overwriting of well-known file system 260 locations (such as "/etc/passwd"). 262 o Many platforms do not use Internet Media Types ([RFC2046]) to hold 263 type information in the file system, but rely on filename 264 extensions instead. Trusting the server-provided file extension 265 could introduce a privilege escalation when the saved file is 266 later opened (consider ".exe"). Thus, recipients SHOULD ensure 267 that a file extension is used that is safe, optimally matching the 268 media type of the received payload. 270 o Recipients SHOULD strip or replace character sequences that are 271 known to cause confusion both in user interfaces and in filenames, 272 such as control characters and leading and trailing whitespace. 274 o Other aspects recipients need to be aware of are names that have a 275 special meaning in the file system or in shell commands, such as 276 "." and "..", "~", "|", and also device names. Recipients SHOULD 277 ignore or substitute names like these. 279 Note: Many user agents do not properly handle the escape character 280 "\" when using the quoted-string form. Furthermore, some user 281 agents erroneously try to perform unescaping of "percent" escapes 282 (see Appendix C.2), and thus might misinterpret filenames 283 containing the percent character followed by two hex digits. 285 4.4. Disposition Parameter: Extensions 287 To enable future extensions, recipients SHOULD ignore unrecognized 288 parameters (see also [RFC2183], Section 2.8). 290 4.5. Extensibility 292 Note that Section 9 of [RFC2183] defines IANA registries both for 293 disposition types and disposition parameters. This registry is 294 shared by different protocols using Content-Disposition, such as MIME 295 and HTTP. Therefore, not all registered values may make sense in the 296 context of HTTP. 298 5. Examples 300 Direct UA to show "save as" dialog, with a filename of 301 "example.html": 303 Content-Disposition: Attachment; filename=example.html 305 Direct UA to behave as if the Content-Disposition header field wasn't 306 present, but to remember the filename "an example.html" for a 307 subsequent save operation: 309 Content-Disposition: INLINE; FILENAME= "an example.html" 311 Note: this uses the quoted-string form so that the space character 312 can be included. 314 Direct UA to show "save as" dialog, with a filename containing the 315 Unicode character U+20AC (EURO SIGN): 317 Content-Disposition: attachment; 318 filename*= UTF-8''%e2%82%ac%20rates 320 Here, the encoding defined in [RFC5987] is also used to encode the 321 non-ISO-8859-1 character. 323 Same as above, but adding the "filename" parameter for compatibility 324 with user agents not implementing RFC 5987: 326 Content-Disposition: attachment; 327 filename="EURO rates"; 328 filename*=utf-8''%e2%82%ac%20rates 330 Note: those user agents that do not support the RFC 5987 encoding 331 ignore "filename*" when it occurs after "filename". 333 6. Internationalization Considerations 335 The "filename*" parameter (Section 4.3), using the encoding defined 336 in [RFC5987], allows the server to transmit characters outside the 337 ISO-8859-1 character set, and also to optionally specify the language 338 in use. 340 Future parameters might also require internationalization, in which 341 case the same encoding can be used. 343 7. Security Considerations 345 Using server-supplied information for constructing local filenames 346 introduces many risks. These are summarized in Section 4.3. 348 Furthermore, implementers also ought to be aware of the Security 349 Considerations applying to HTTP (see Section 15 of [RFC2616]), and 350 also the parameter encoding defined in [RFC5987] (see Section 5). 352 8. IANA Considerations 354 8.1. Registry for Disposition Values and Parameter 356 This specification does not introduce any changes to the registration 357 procedures for disposition values and parameters that are defined in 358 Section 9 of [RFC2183]. 360 8.2. Header Field Registration 362 This document updates the definition of the Content-Disposition HTTP 363 header field in the permanent HTTP header field registry (see 364 [RFC3864]). 366 Header field name: Content-Disposition 368 Applicable protocol: http 370 Status: standard 372 Author/Change controller: IETF 374 Specification document: this specification (Section 4) 376 9. Acknowledgements 378 Thanks to Adam Barth, Rolf Eike Beer, Bjoern Hoehrmann, Alfred 379 Hoenes, Roar Lauritzsen, Henrik Nordstrom, and Mark Nottingham for 380 their valuable feedback. 382 10. References 384 10.1. Normative References 386 [ISO-8859-1] International Organization for Standardization, 387 "Information technology -- 8-bit single-byte coded 388 graphic character sets -- Part 1: Latin alphabet No. 389 1", ISO/IEC 8859-1:1998, 1998. 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, March 1997. 394 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 395 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 396 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 398 [RFC5987] Reschke, J., "Character Set and Language Encoding for 399 Hypertext Transfer Protocol (HTTP) Header Field 400 Parameters", RFC 5987, August 2010. 402 10.2. Informative References 404 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet 405 Mail Extensions (MIME) Part Two: Media Types", 406 RFC 2046, November 1996. 408 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail 409 Extensions) Part Three: Message Header Extensions for 410 Non-ASCII Text", RFC 2047, November 1996. 412 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 413 Presentation Information in Internet Messages: The 414 Content-Disposition Header Field", RFC 2183, 415 August 1997. 417 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and 418 Encoded Word Extensions: Character Sets, Languages, and 419 Continuations", RFC 2231, November 1997. 421 [RFC2388] Masinter, L., "Returning Values from Forms: multipart/ 422 form-data", RFC 2388, August 1998. 424 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 425 Procedures for Message Header Fields", BCP 90, 426 RFC 3864, September 2004. 428 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, 429 "Uniform Resource Identifier (URI): Generic Syntax", 430 STD 66, RFC 3986, January 2005. 432 Appendix A. Changes from the RFC 2616 Definition 434 Compared to Section 19.5.1 of [RFC2616], the following normative 435 changes reflecting actual implementations have been made: 437 o According to RFC 2616, the disposition type "attachment" only 438 applies to content of type "application/octet-stream". This 439 restriction has been removed, because recipients in practice do 440 not check the content type, and it also discourages properly 441 declaring the media type. 443 o RFC 2616 only allows "quoted-string" for the filename parameter. 444 This would be an exceptional parameter syntax, and also doesn't 445 reflect actual use. 447 o The definition for the disposition type "inline" ([RFC2183], 448 Section 2.1) has been re-added with a suggestion for its 449 processing. 451 o This specification requires support for the extended parameter 452 encoding defined in [RFC5987]. 454 Appendix B. Differences compared to RFC 2183 456 Section 2 of [RFC2183] defines several additional disposition 457 parameters: "creation-date", "modification-date", "quoted-date-time", 458 and "size". The majority of user agents does not implement these, 459 thus they have been omitted from this specification. 461 Appendix C. Alternative Approaches to Internationalization 463 By default, HTTP header field parameters cannot carry characters 464 outside the ISO-8859-1 ([ISO-8859-1]) character encoding (see 465 [RFC2616], Section 2.2). For the "filename" parameter, this of 466 course is an unacceptable restriction. 468 Unfortunately, user agent implementers have not managed to come up 469 with an interoperable approach, although the IETF Standards Track 470 specifies exactly one solution ([RFC2231], clarified and profiled for 471 HTTP in [RFC5987]). 473 For completeness, the sections below describe the various approaches 474 that have been tried, and explains how they are inferior to the RFC 475 5987 encoding used in this specification. 477 C.1. RFC 2047 Encoding 479 RFC 2047 defines an encoding mechanism for header fields, but this 480 encoding is not supposed to be used for header field parameters - see 481 Section 5 of [RFC2047]: 483 An 'encoded-word' MUST NOT appear within a 'quoted-string'. 485 ... 487 An 'encoded-word' MUST NOT be used in parameter of a MIME Content- 488 Type or Content-Disposition field, or in any structured field body 489 except within a 'comment' or 'phrase'. 491 In practice, some user agents implement the encoding, some do not 492 (exposing the encoded string to the user), and some get confused by 493 it. 495 C.2. Percent Encoding 497 Some user agents accept percent encoded ([RFC3986], Section 2.1) 498 sequences of characters. The character encoding being used for 499 decoding depends on various factors, including the encoding of the 500 referring page, the user agent's locale, its configuration, and also 501 the actual value of the parameter. 503 In practice, this is hard to use because those user agents that do 504 not support it will display the escaped character sequence to the 505 user. For those user agents that do implement this it is difficult 506 to predict what character encoding they actually expect. 508 C.3. Encoding Sniffing 510 Some user agents inspect the value (which defaults to ISO-8859-1 for 511 the quoted-string form) and switch to UTF-8 when it seems to be more 512 likely to be the correct interpretation. 514 As with the approaches above, this is not interoperable and 515 furthermore risks misinterpreting the actual value. 517 C.4. Implementations (to be removed by RFC Editor before publication) 519 Unfortunately, as of March 2011, neither the encoding defined in RFCs 520 2231 and 5987, nor any of the alternate approaches discussed above 521 was implemented interoperably. Thus, this specification recommends 522 the approach defined in RFC 5987, which at least has the advantage of 523 actually being specified properly. 525 The table below shows the implementation support for the various 526 approaches: 528 +---------------+------------+--------+--------------+--------------+ 529 | User Agent | RFC | RFC | Percent | Encoding | 530 | | 2231/5987 | 2047 | Encoding | Sniffing | 531 +---------------+------------+--------+--------------+--------------+ 532 | Chrome | yes | yes | yes | yes | 533 | Firefox | yes (*) | yes | no | yes | 534 | Internet | yes (**) | no | yes | no | 535 | Explorer | | | | | 536 | Konqueror | yes | no | no | no | 537 | Opera | yes | no | no | no | 538 | Safari | no | no | no | yes | 539 +---------------+------------+--------+--------------+--------------+ 541 (*) Does not implement the fallback behavior to "filename" described 542 in Section 4.3; a fix is planned for Firefox 5. 544 (**) Starting with IE9RC, but only implements UTF-8. 546 Appendix D. Advice on Generating Content-Disposition Header Fields 548 To successfully interoperate with existing and future user agents, 549 senders of the Content-Disposition header field are advised to: 551 o Include a "filename" parameter when US-ASCII is sufficiently 552 expressive. 554 o Use the 'token' form of the filename parameter only when it does 555 not contain disallowed characters (e.g., spaces); in such cases, 556 the quoted-string form should be used. 558 o Avoid including the percent character followed by two hexadecimal 559 characters (e.g., %A9) in the filename parameter, since some 560 existing implementations consider it to be an escape character, 561 while others will pass it through unchanged. 563 o Avoid including the "\" character in the quoted-string form of the 564 filename parameter, as escaping is not implemented by some user 565 agents, and can be considered as an illegal path character. 567 o Avoid using non-ASCII characters in the filename parameter. 568 Although most existing implementations will decode them as ISO- 569 8859-1, some will apply heuristics to detect UTF-8, and thus might 570 fail on certain names. 572 o Include a "filename*" parameter where the desired filename cannot 573 be expressed faithfully using the "filename" form. Note that 574 legacy user agents will not process this, and will fall back to 575 using the "filename" parameter's content. 577 o When a "filename*" parameter is sent, to also generate a 578 "filename" parameter as a fallback for user agents that do not 579 support the "filename*" form, if possible. This can be done by 580 substituting characters with US-ASCII sequences (e.g., Unicode 581 character point U+00E4 (LATIN SMALL LETTER A WITH DIARESIS) by 582 "ae"). Note that this may not be possible in some locales. 584 o When a "filename" parameter is included as a fallback (as per 585 above), "filename" should occur first, due to parsing problems in 586 some existing implementations. [[fallbackbug: Firefox is known to 587 pick the wrong parameter; a bug fix is scheduled for Firefox 5. 588 --jre]] 590 o Use UTF-8 as the encoding of the "filename*" parameter, when 591 present, because at least one existing implementation only 592 implements that encoding. 594 Note that this advice is based upon UA behaviour at the time of 595 writing, and might be superseded. 596 provides an 597 overview of current levels of support in various implementations. 599 Appendix E. Change Log (to be removed by RFC Editor before publication) 601 Note: the issues names in the change log entries for 602 draft-reschke-rfc2183-in-http refer to . 605 E.1. Since draft-reschke-rfc2183-in-http-00 607 Adjust terminology ("header" -> "header field"). Update rfc2231-in- 608 http reference. 610 E.2. Since draft-reschke-rfc2183-in-http-01 612 Update rfc2231-in-http reference. Actually define the "filename" 613 parameter. Add internationalization considerations. Add examples 614 using the RFC 5987 encoding. Add overview over other approaches, 615 plus a table reporting implementation status. Add and resolve issue 616 "nodep2183". Add issues "asciivsiso", "deplboth", "quoted", and 617 "registry". 619 E.3. Since draft-reschke-rfc2183-in-http-02 621 Add and close issue "docfallback". Close issues "asciivsiso", 622 "deplboth", "quoted", and "registry". 624 E.4. Since draft-reschke-rfc2183-in-http-03 626 Updated to be a Working Draft of the IETF HTTPbis Working Group. 628 E.5. Since draft-ietf-httpbis-content-disp-00 630 Closed issues: 632 o : "handling of 633 unknown disposition types" 635 Slightly updated the notes about the proposed fallback behavior. 637 E.6. Since draft-ietf-httpbis-content-disp-01 639 Various editorial improvements. 641 E.7. Since draft-ietf-httpbis-content-disp-02 643 Closed issues: 645 o : "state that 646 repeating parameters are invalid" 648 o : "warn about 649 %xx in filenames being misinterpreted" 651 o : "mention 652 control chars when talking about postprecessing the filename 653 parameter" 655 Update Appendix C.4; Opera 10.63 RC implements the recommended 656 fallback behavior. 658 E.8. Since draft-ietf-httpbis-content-disp-03 660 Closed issues: 662 o : 663 "'modification-date' *is* implemented in Konq 4.5" 665 o : "clarify what 666 LWS means for the Content-Disp grammar" 668 o : "Avoid passive 669 voice in message requirements" 671 o : "text about 672 historical percent-decoding unclear" 674 o : "add 675 explanation of language tagging" 677 o : "Clarify that 678 C-D spec does not apply to multipart upload" 680 E.9. Since draft-ietf-httpbis-content-disp-04 682 Updated implementation information (Chrome 9 implements RFC 5987, IE 683 9 RC implements it for UTF-8 only). 685 Clarify who requirements are on, add a section discussing conformance 686 and handling of invalid field values in general. 688 Closed issues: 690 o : "avoid 691 stating ISO-8859-1 default for header param" (the default is still 692 mentioned, but it was clarified what it applies to). 694 o : "Path 695 Separator Characters" 697 E.10. Since draft-ietf-httpbis-content-disp-05 699 Editorial changes: Fixed two typos where the new Conformance section 700 said "Content-Location" instead of "Content-Disposition". Cleaned up 701 terminology ("user agent", "recipient", "sender", "message body", 702 ...). Stated what the escape character for quoted-string is. 703 Explained a use case for "inline" disposition type. Updated 704 implementation notes with respect to the fallback behavior. 706 Added appendix "Advice on Generating Content-Disposition Header 707 Fields". 709 E.11. Since draft-ietf-httpbis-content-disp-06 711 Closed issues: 713 o : 714 "conformance language" 716 Index 718 C 719 Content-Disposition header field 5 721 H 722 Header Fields 723 Content-Disposition 5 725 Author's Address 727 Julian F. Reschke 728 greenbytes GmbH 729 Hafenweg 16 730 Muenster, NW 48155 731 Germany 733 EMail: julian.reschke@greenbytes.de 734 URI: http://greenbytes.de/tech/webdav/