source: draft-ietf-httpbis-content-disp/05/draft-ietf-httpbis-content-disp-05.txt @ 2684

Last change on this file since 2684 was 1119, checked in by julian.reschke@…, 10 years ago

Prepare C-D draft 05.

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 28.7 KB
Line 
1
2
3
4HTTPbis Working Group                                         J. Reschke
5Internet-Draft                                                greenbytes
6Updates: 2616 (if approved)                            February 17, 2011
7Intended status: Standards Track
8Expires: August 21, 2011
9
10
11           Use of the Content-Disposition Header Field in the
12                   Hypertext Transfer Protocol (HTTP)
13                   draft-ietf-httpbis-content-disp-05
14
15Abstract
16
17   HTTP/1.1 defines the Content-Disposition response header field, but
18   points out that it is not part of the HTTP/1.1 Standard.  This
19   specification takes over the definition and registration of Content-
20   Disposition, as used in HTTP, and clarifies internationalization
21   aspects.
22
23Editorial Note (To be removed by RFC Editor before publication)
24
25   This specification is expected to replace the definition of Content-
26   Disposition in the HTTP/1.1 specification, as currently revised by
27   the IETF HTTPbis working group.  See also
28   <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/123>.
29
30   Discussion of this draft should take place on the HTTPBIS working
31   group mailing list (ietf-http-wg@w3.org).  The current issues list is
32   at <http://trac.tools.ietf.org/wg/httpbis/trac/
33   query?component=content-disp> and related documents (including fancy
34   diffs) can be found at <http://tools.ietf.org/wg/httpbis/>.
35
36   The changes in this draft are summarized in Appendix D.9.
37
38Status of This Memo
39
40   This Internet-Draft is submitted in full conformance with the
41   provisions of BCP 78 and BCP 79.
42
43   Internet-Drafts are working documents of the Internet Engineering
44   Task Force (IETF).  Note that other groups may also distribute
45   working documents as Internet-Drafts.  The list of current Internet-
46   Drafts is at http://datatracker.ietf.org/drafts/current/.
47
48   Internet-Drafts are draft documents valid for a maximum of six months
49   and may be updated, replaced, or obsoleted by other documents at any
50   time.  It is inappropriate to use Internet-Drafts as reference
51   material or to cite them other than as "work in progress."
52
53
54
55Reschke                  Expires August 21, 2011                [Page 1]
56
57Internet-Draft         Content-Disposition in HTTP         February 2011
58
59
60   This Internet-Draft will expire on August 21, 2011.
61
62Copyright Notice
63
64   Copyright (c) 2011 IETF Trust and the persons identified as the
65   document authors.  All rights reserved.
66
67   This document is subject to BCP 78 and the IETF Trust's Legal
68   Provisions Relating to IETF Documents
69   (http://trustee.ietf.org/license-info) in effect on the date of
70   publication of this document.  Please review these documents
71   carefully, as they describe your rights and restrictions with respect
72   to this document.  Code Components extracted from this document must
73   include Simplified BSD License text as described in Section 4.e of
74   the Trust Legal Provisions and are provided without warranty as
75   described in the Simplified BSD License.
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Reschke                  Expires August 21, 2011                [Page 2]
112
113Internet-Draft         Content-Disposition in HTTP         February 2011
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  4
120   3.  Conformance and Error Handling . . . . . . . . . . . . . . . .  4
121   4.  Header Field Definition  . . . . . . . . . . . . . . . . . . .  5
122     4.1.  Grammar  . . . . . . . . . . . . . . . . . . . . . . . . .  5
123     4.2.  Disposition Type . . . . . . . . . . . . . . . . . . . . .  6
124     4.3.  Disposition Parameter: 'Filename'  . . . . . . . . . . . .  6
125     4.4.  Disposition Parameter: Extensions  . . . . . . . . . . . .  7
126     4.5.  Extensibility  . . . . . . . . . . . . . . . . . . . . . .  7
127   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
128   6.  Internationalization Considerations  . . . . . . . . . . . . .  8
129   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
130   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
131     8.1.  Registry for Disposition Values and Parameter  . . . . . .  9
132     8.2.  Header Field Registration  . . . . . . . . . . . . . . . .  9
133   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
134   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
135     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
136     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
137   Appendix A.  Changes from the RFC 2616 Definition  . . . . . . . . 10
138   Appendix B.  Differences compared to RFC 2183  . . . . . . . . . . 11
139   Appendix C.  Alternative Approaches to Internationalization  . . . 11
140     C.1.  RFC 2047 Encoding  . . . . . . . . . . . . . . . . . . . . 11
141     C.2.  Percent Encoding . . . . . . . . . . . . . . . . . . . . . 12
142     C.3.  Encoding Sniffing  . . . . . . . . . . . . . . . . . . . . 12
143     C.4.  Implementations (to be removed by RFC Editor before
144           publication) . . . . . . . . . . . . . . . . . . . . . . . 12
145   Appendix D.  Change Log (to be removed by RFC Editor before
146                publication)  . . . . . . . . . . . . . . . . . . . . 13
147     D.1.  Since draft-reschke-rfc2183-in-http-00 . . . . . . . . . . 13
148     D.2.  Since draft-reschke-rfc2183-in-http-01 . . . . . . . . . . 13
149     D.3.  Since draft-reschke-rfc2183-in-http-02 . . . . . . . . . . 13
150     D.4.  Since draft-reschke-rfc2183-in-http-03 . . . . . . . . . . 13
151     D.5.  Since draft-ietf-httpbis-content-disp-00 . . . . . . . . . 13
152     D.6.  Since draft-ietf-httpbis-content-disp-01 . . . . . . . . . 13
153     D.7.  Since draft-ietf-httpbis-content-disp-02 . . . . . . . . . 13
154     D.8.  Since draft-ietf-httpbis-content-disp-03 . . . . . . . . . 14
155     D.9.  Since draft-ietf-httpbis-content-disp-04 . . . . . . . . . 14
156   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
157
158
159
160
161
162
163
164
165
166
167Reschke                  Expires August 21, 2011                [Page 3]
168
169Internet-Draft         Content-Disposition in HTTP         February 2011
170
171
1721.  Introduction
173
174   HTTP/1.1 defines the Content-Disposition response header field in
175   Section 19.5.1 of [RFC2616], but points out that it is not part of
176   the HTTP/1.1 Standard (Section 15.5):
177
178      Content-Disposition is not part of the HTTP standard, but since it
179      is widely implemented, we are documenting its use and risks for
180      implementers.
181
182   This specification takes over the definition and registration of
183   Content-Disposition, as used in HTTP.  Based on interoperability
184   testing with existing User Agents, it fully defines a profile of the
185   features defined in the Multipurpose Internet Mail Extensions (MIME)
186   variant ([RFC2183]) of the header field, and also clarifies
187   internationalization aspects.
188
189      Note: this document does not apply to Content-Disposition header
190      fields appearing in message payloads transmitted over HTTP, such
191      as when using the media type "multipart/form-data" ([RFC2388]).
192
1932.  Notational Conventions
194
195   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
196   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
197   document are to be interpreted as described in [RFC2119].
198
199   This specification uses the augmented BNF notation defined in Section
200   2.1 of [RFC2616], including its rules for implied linear whitespace
201   (LWS).
202
2033.  Conformance and Error Handling
204
205   This specification defines conformance criteria for both senders
206   (usually, HTTP origin servers) and recipients (usually, HTTP user
207   agents) of the Content-Location header field.  An implementation is
208   considered conformant if it complies with all of the requirements
209   associated with its role.
210
211   This specification also defines certain forms of the header field-
212   value to be invalid, using both ABNF and prose requirements, but it
213   does not define special handling of these invalid field-values.
214
215   Sending implementations MUST NOT generate Content-Location header
216   fields that are invalid.
217
218   Consuming implementations MAY take steps to recover a usable field-
219   value from an invalid header field, but SHOULD NOT reject the message
220
221
222
223Reschke                  Expires August 21, 2011                [Page 4]
224
225Internet-Draft         Content-Disposition in HTTP         February 2011
226
227
228   outright, unless this is explicitly desirable behaviour (e.g., the
229   implementation is a validator).  As such, the default handling of
230   invalid fields is to ignore them.
231
2324.  Header Field Definition
233
234   The Content-Disposition response header field is used to convey
235   additional information about how to process the response payload, and
236   also can be used to attach additional metadata, such as the filename
237   to use when saving the response payload locally.
238
2394.1.  Grammar
240
241     content-disposition = "Content-Disposition" ":"
242                            disposition-type *( ";" disposition-parm )
243
244     disposition-type    = "inline" | "attachment" | disp-ext-type
245                         ; case-insensitive
246     disp-ext-type       = token
247
248     disposition-parm    = filename-parm | disp-ext-parm
249
250     filename-parm       = "filename" "=" value
251                         | "filename*" "=" ext-value
252
253     disp-ext-parm       = token "=" value
254                         | ext-token "=" ext-value
255     ext-token           = <the characters in token, followed by "*">
256
257   Defined in [RFC2616]:
258
259     token         = <token, defined in [RFC2616], Section 2.2>
260     quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
261     value         = <value, defined in [RFC2616], Section 3.6>
262                   ; token | quoted-string
263
264
265   Defined in [RFC5987]:
266
267     ext-value   = <ext-value, defined in [RFC5987], Section 3.2>
268
269   Header field values with multiple instances of the same parameter
270   name are invalid.
271
272   Note that due to the rules for implied linear whitespace (Section 2.1
273   of [RFC2616]), OPTIONAL whitespace can appear between words (token or
274   quoted-string) and separator characters.
275
276
277
278
279Reschke                  Expires August 21, 2011                [Page 5]
280
281Internet-Draft         Content-Disposition in HTTP         February 2011
282
283
284   Furthermore note that the format used for ext-value allows specifying
285   a natural language; this is of limited use for filenames and is
286   likely to be ignored by recipients.
287
2884.2.  Disposition Type
289
290   If the disposition type matches "attachment" (case-insensitively),
291   this indicates that the user agent should prompt the user to save the
292   response locally, rather than process it normally (as per its media
293   type).
294
295   On the other hand, if it matches "inline" (case-insensitively), this
296   implies default processing.
297
298   Unknown or unhandled disposition types SHOULD be handled by
299   recipients the same way as "attachment" (see also [RFC2183], Section
300   2.8).
301
3024.3.  Disposition Parameter: 'Filename'
303
304   The parameters "filename" and "filename*", to be matched case-
305   insensitively, provide information on how to construct a filename for
306   storing the message payload.
307
308   Depending on the disposition type, this information might be used
309   right away (in the "save as..." interaction caused for the
310   "attachment" disposition type), or later on (for instance, when the
311   user decides to save the contents of the current page being
312   displayed).
313
314   The parameters "filename" and "filename*" differ only in that
315   "filename*" uses the encoding defined in [RFC5987], allowing the use
316   of characters not present in the ISO-8859-1 character set
317   ([ISO-8859-1]).
318
319   Many user agent implementations predating this specification do not
320   understand the "filename*" parameter.  Therefore, when both
321   "filename" and "filename*" are present in a single header field
322   value, recipients SHOULD pick "filename*" and ignore "filename".
323   This way, senders can avoid special-casing specific user agents by
324   sending both the more expressive "filename*" parameter, and the
325   "filename" parameter as fallback for legacy recipients (see Section 5
326   for an example).
327
328   It is essential that user agents treat the specified filename as
329   advisory only, thus be very careful in extracting the desired
330   information.  In particular:
331
332
333
334
335Reschke                  Expires August 21, 2011                [Page 6]
336
337Internet-Draft         Content-Disposition in HTTP         February 2011
338
339
340   o  When the value contains path separator characters ("\" or "/"),
341      recipients SHOULD ignore all but the last path segment.  This
342      prevents unintentional overwriting of well-known file system
343      locations (such as "/etc/passwd").
344
345   o  Many platforms do not use Internet Media Types ([RFC2046]) to hold
346      type information in the file system, but rely on filename
347      extensions instead.  Trusting the server-provided file extension
348      could introduce a privilege escalation when the saved file is
349      later opened (consider ".exe").  Thus, recipients need to ensure
350      that a file extension is used that is safe, optimally matching the
351      media type of the received payload.
352
353   o  Recipients are advised to strip or replace character sequences
354      that are known to cause confusion both in user interfaces and in
355      filenames, such as control characters and leading and trailing
356      whitespace.
357
358   o  Other aspects recipients need to be aware of are names that have a
359      special meaning in the file system or in shell commands, such as
360      "." and "..", "~", "|", and also device names.
361
362      Note: Many user agents do not properly handle escape characters
363      when using the quoted-string form.  Furthermore, some user agents
364      erroneously try to perform unescaping of "percent" escapes (see
365      Appendix C.2), and thus might misinterpret filenames containing
366      the percent character followed by two hex digits.
367
3684.4.  Disposition Parameter: Extensions
369
370   To enable future extensions, recipients SHOULD ignore unrecognized
371   parameters (see also [RFC2183], Section 2.8).
372
3734.5.  Extensibility
374
375   Note that Section 9 of [RFC2183] defines IANA registries both for
376   disposition types and disposition parameters.  This registry is
377   shared by different protocols using Content-Disposition, such as MIME
378   and HTTP.  Therefore, not all registered values may make sense in the
379   context of HTTP.
380
3815.  Examples
382
383   Direct UA to show "save as" dialog, with a filename of
384   "example.html":
385
386   Content-Disposition: Attachment; filename=example.html
387
388
389
390
391Reschke                  Expires August 21, 2011                [Page 7]
392
393Internet-Draft         Content-Disposition in HTTP         February 2011
394
395
396   Direct UA to behave as if the Content-Disposition header field wasn't
397   present, but to remember the filename "an example.html" for a
398   subsequent save operation:
399
400     Content-Disposition: INLINE; FILENAME= "an example.html"
401
402   Note: this uses the quoted-string form so that the space character
403   can be included.
404
405   Direct UA to show "save as" dialog, with a filename containing the
406   Unicode character U+20AC (EURO SIGN):
407
408     Content-Disposition: attachment;
409                          filename*= UTF-8''%e2%82%ac%20rates
410
411   Here, the encoding defined in [RFC5987] is also used to encode the
412   non-ISO-8859-1 character.
413
414   Same as above, but adding the "filename" parameter for compatibility
415   with user agents not implementing RFC 5987:
416
417     Content-Disposition: attachment;
418                          filename="EURO rates";
419                          filename*=utf-8''%e2%82%ac%20rates
420
421   Note: as of February 2011, those user agents that do not support the
422   RFC 5987 encoding ignore "filename*" when it occurs after "filename".
423   Unfortunately, some user agents that do support RFC 5987 do pick the
424   "filename" rather than the "filename*" parameter when it occurs
425   first; it is expected that this situation is going to improve soon.
426
4276.  Internationalization Considerations
428
429   The "filename*" parameter (Section 4.3), using the encoding defined
430   in [RFC5987], allows the server to transmit characters outside the
431   ISO-8859-1 character set, and also to optionally specify the language
432   in use.
433
434   Future parameters might also require internationalization, in which
435   case the same encoding can be used.
436
4377.  Security Considerations
438
439   Using server-supplied information for constructing local filenames
440   introduces many risks.  These are summarized in Section 4.3.
441
442   Furthermore, implementers also ought to be aware of the Security
443   Considerations applying to HTTP (see Section 15 of [RFC2616]), and
444
445
446
447Reschke                  Expires August 21, 2011                [Page 8]
448
449Internet-Draft         Content-Disposition in HTTP         February 2011
450
451
452   also the parameter encoding defined in [RFC5987] (see Section 5).
453
4548.  IANA Considerations
455
4568.1.  Registry for Disposition Values and Parameter
457
458   This specification does not introduce any changes to the registration
459   procedures for disposition values and parameters that are defined in
460   Section 9 of [RFC2183].
461
4628.2.  Header Field Registration
463
464   This document updates the definition of the Content-Disposition HTTP
465   header field in the permanent HTTP header field registry (see
466   [RFC3864]).
467
468   Header field name:  Content-Disposition
469
470   Applicable protocol:  http
471
472   Status:  standard
473
474   Author/Change controller:  IETF
475
476   Specification document:  this specification (Section 4)
477
4789.  Acknowledgements
479
480   Thanks to Adam Barth, Rolf Eike Beer, Bjoern Hoehrmann, Alfred
481   Hoenes, Roar Lauritzsen, Henrik Nordstrom, and Mark Nottingham for
482   their valuable feedback.
483
48410.  References
485
48610.1.  Normative References
487
488   [ISO-8859-1]  International Organization for Standardization,
489                 "Information technology -- 8-bit single-byte coded
490                 graphic character sets -- Part 1: Latin alphabet No.
491                 1", ISO/IEC 8859-1:1998, 1998.
492
493   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
494                 Requirement Levels", BCP 14, RFC 2119, March 1997.
495
496   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
497                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
498                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
499
500
501
502
503Reschke                  Expires August 21, 2011                [Page 9]
504
505Internet-Draft         Content-Disposition in HTTP         February 2011
506
507
508   [RFC5987]     Reschke, J., "Character Set and Language Encoding for
509                 Hypertext Transfer Protocol (HTTP) Header Field
510                 Parameters", RFC 5987, August 2010.
511
51210.2.  Informative References
513
514   [RFC2046]     Freed, N. and N. Borenstein, "Multipurpose Internet
515                 Mail Extensions (MIME) Part Two: Media Types",
516                 RFC 2046, November 1996.
517
518   [RFC2047]     Moore, K., "MIME (Multipurpose Internet Mail
519                 Extensions) Part Three: Message Header Extensions for
520                 Non-ASCII Text", RFC 2047, November 1996.
521
522   [RFC2183]     Troost, R., Dorner, S., and K. Moore, "Communicating
523                 Presentation Information in Internet Messages: The
524                 Content-Disposition Header Field", RFC 2183,
525                 August 1997.
526
527   [RFC2231]     Freed, N. and K. Moore, "MIME Parameter Value and
528                 Encoded Word Extensions: Character Sets, Languages, and
529                 Continuations", RFC 2231, November 1997.
530
531   [RFC2388]     Masinter, L., "Returning Values from Forms: multipart/
532                 form-data", RFC 2388, August 1998.
533
534   [RFC3864]     Klyne, G., Nottingham, M., and J. Mogul, "Registration
535                 Procedures for Message Header Fields", BCP 90,
536                 RFC 3864, September 2004.
537
538   [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
539                 "Uniform Resource Identifier (URI): Generic Syntax",
540                 STD 66, RFC 3986, January 2005.
541
542Appendix A.  Changes from the RFC 2616 Definition
543
544   Compared to Section 19.5.1 of [RFC2616], the following normative
545   changes reflecting actual implementations have been made:
546
547   o  According to RFC 2616, the disposition type "attachment" only
548      applies to content of type "application/octet-stream".  This
549      restriction has been removed, because user agents in practice do
550      not check the content type, and it also discourages properly
551      declaring the media type.
552
553   o  RFC 2616 only allows "quoted-string" for the filename parameter.
554      This would be an exceptional parameter syntax, and also doesn't
555      reflect actual use.
556
557
558
559Reschke                  Expires August 21, 2011               [Page 10]
560
561Internet-Draft         Content-Disposition in HTTP         February 2011
562
563
564   o  The definition for the disposition type "inline" ([RFC2183],
565      Section 2.1) has been re-added with a suggestion for its
566      processing.
567
568   o  This specification requires support for the extended parameter
569      encoding defined in [RFC5987].
570
571Appendix B.  Differences compared to RFC 2183
572
573   Section 2 of [RFC2183] defines several additional disposition
574   parameters: "creation-date", "modification-date", "quoted-date-time",
575   and "size".  The majority of user agents does not implement these,
576   thus they have been omitted from this specification.
577
578Appendix C.  Alternative Approaches to Internationalization
579
580   By default, HTTP header field parameters cannot carry characters
581   outside the ISO-8859-1 ([ISO-8859-1]) character encoding (see
582   [RFC2616], Section 2.2).  For the "filename" parameter, this of
583   course is an unacceptable restriction.
584
585   Unfortunately, user agent implementers have not managed to come up
586   with an interoperable approach, although the IETF Standards Track
587   specifies exactly one solution ([RFC2231], clarified and profiled for
588   HTTP in [RFC5987]).
589
590   For completeness, the sections below describe the various approaches
591   that have been tried, and explains how they are inferior to the RFC
592   5987 encoding used in this specification.
593
594C.1.  RFC 2047 Encoding
595
596   RFC 2047 defines an encoding mechanism for header fields, but this
597   encoding is not supposed to be used for header field parameters - see
598   Section 5 of [RFC2047]:
599
600      An 'encoded-word' MUST NOT appear within a 'quoted-string'.
601
602      ...
603
604      An 'encoded-word' MUST NOT be used in parameter of a MIME Content-
605      Type or Content-Disposition field, or in any structured field body
606      except within a 'comment' or 'phrase'.
607
608   In practice, some user agents implement the encoding, some do not
609   (exposing the encoded string to the user), and some get confused by
610   it.
611
612
613
614
615Reschke                  Expires August 21, 2011               [Page 11]
616
617Internet-Draft         Content-Disposition in HTTP         February 2011
618
619
620C.2.  Percent Encoding
621
622   Some user agents accept percent encoded ([RFC3986], Section 2.1)
623   sequences of characters.  The character encoding being used for
624   decoding depends on various factors, including the encoding of the
625   referring page, the user agent's locale, its configuration, and also
626   the actual value of the parameter.
627
628   In practice, this is hard to use because those user agents that do
629   not support it will display the escaped character sequence to the
630   user.  For those user agents that do implement this it is difficult
631   to predict what character encoding they actually expect.
632
633C.3.  Encoding Sniffing
634
635   Some user agents inspect the value (which defaults to ISO-8859-1 for
636   the quoted-string form) and switch to UTF-8 when it seems to be more
637   likely to be the correct interpretation.
638
639   As with the approaches above, this is not interoperable and
640   furthermore risks misinterpreting the actual value.
641
642C.4.  Implementations (to be removed by RFC Editor before publication)
643
644   Unfortunately, as of February 2011, neither the encoding defined in
645   RFCs 2231 and 5987, nor any of the alternate approaches discussed
646   above was implemented interoperably.  Thus, this specification
647   recommends the approach defined in RFC 5987, which at least has the
648   advantage of actually being specified properly.
649
650   The table below shows the implementation support for the various
651   approaches:
652
653   +---------------+------------+--------+--------------+--------------+
654   | User Agent    | RFC        | RFC    | Percent      | Encoding     |
655   |               | 2231/5987  | 2047   | Encoding     | Sniffing     |
656   +---------------+------------+--------+--------------+--------------+
657   | Chrome        | yes        | yes    | yes          | yes          |
658   | Firefox       | yes (*)    | yes    | no           | yes          |
659   | Internet      | yes (**)   | no     | yes          | no           |
660   | Explorer      |            |        |              |              |
661   | Konqueror     | yes        | no     | no           | no           |
662   | Opera         | yes        | no     | no           | no           |
663   | Safari        | no         | no     | no           | yes          |
664   +---------------+------------+--------+--------------+--------------+
665
666   (*) Does not implement the fallback behavior to "filename" described
667   in Section 4.3.
668
669
670
671Reschke                  Expires August 21, 2011               [Page 12]
672
673Internet-Draft         Content-Disposition in HTTP         February 2011
674
675
676   (**) Starting with IE9RC, but only implements UTF-8.
677
678Appendix D.  Change Log (to be removed by RFC Editor before publication)
679
680   Note: the issues names in the change log entries for
681   draft-reschke-rfc2183-in-http refer to <http://greenbytes.de/tech/
682   webdav/draft-reschke-rfc2183-in-http-issues.html>.
683
684D.1.  Since draft-reschke-rfc2183-in-http-00
685
686   Adjust terminology ("header" -> "header field").  Update rfc2231-in-
687   http reference.
688
689D.2.  Since draft-reschke-rfc2183-in-http-01
690
691   Update rfc2231-in-http reference.  Actually define the "filename"
692   parameter.  Add internationalization considerations.  Add examples
693   using the RFC 5987 encoding.  Add overview over other approaches,
694   plus a table reporting implementation status.  Add and resolve issue
695   "nodep2183".  Add issues "asciivsiso", "deplboth", "quoted", and
696   "registry".
697
698D.3.  Since draft-reschke-rfc2183-in-http-02
699
700   Add and close issue "docfallback".  Close issues "asciivsiso",
701   "deplboth", "quoted", and "registry".
702
703D.4.  Since draft-reschke-rfc2183-in-http-03
704
705   Updated to be a Working Draft of the IETF HTTPbis Working Group.
706
707D.5.  Since draft-ietf-httpbis-content-disp-00
708
709   Closed issues:
710
711   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/242>: "handling of
712      unknown disposition types"
713
714   Slightly updated the notes about the proposed fallback behavior.
715
716D.6.  Since draft-ietf-httpbis-content-disp-01
717
718   Various editorial improvements.
719
720D.7.  Since draft-ietf-httpbis-content-disp-02
721
722   Closed issues:
723
724
725
726
727Reschke                  Expires August 21, 2011               [Page 13]
728
729Internet-Draft         Content-Disposition in HTTP         February 2011
730
731
732   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/244>: "state that
733      repeating parameters are invalid"
734
735   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/245>: "warn about
736      %xx in filenames being misinterpreted"
737
738   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/246>: "mention
739      control chars when talking about postprecessing the filename
740      parameter"
741
742   Update Appendix C.4; Opera 10.63 RC implements the recommended
743   fallback behavior.
744
745D.8.  Since draft-ietf-httpbis-content-disp-03
746
747   Closed issues:
748
749   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/252>:
750      "'modification-date' *is* implemented in Konq 4.5"
751
752   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/253>: "clarify what
753      LWS means for the Content-Disp grammar"
754
755   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/258>: "Avoid passive
756      voice in message requirements"
757
758   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/263>: "text about
759      historical percent-decoding unclear"
760
761   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/264>: "add
762      explanation of language tagging"
763
764   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/265>: "Clarify that
765      C-D spec does not apply to multipart upload"
766
767D.9.  Since draft-ietf-httpbis-content-disp-04
768
769   Updated implementation information (Chrome 9 implements RFC 5987, IE
770   9 RC implements it for UTF-8 only).
771
772   Clarify who requirements are on, add a section discussing conformance
773   and handling of invalid field values in general.
774
775   Closed issues:
776
777   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/272>: "Path
778      Separator Characters"
779
780
781
782
783Reschke                  Expires August 21, 2011               [Page 14]
784
785Internet-Draft         Content-Disposition in HTTP         February 2011
786
787
788Index
789
790   C
791      Content-Disposition header  5
792
793   H
794      Headers
795         Content-Disposition  5
796
797Author's Address
798
799   Julian F. Reschke
800   greenbytes GmbH
801   Hafenweg 16
802   Muenster, NW  48155
803   Germany
804
805   EMail: julian.reschke@greenbytes.de
806   URI:   http://greenbytes.de/tech/webdav/
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839Reschke                  Expires August 21, 2011               [Page 15]
840
Note: See TracBrowser for help on using the repository browser.