source: draft-ietf-httpbis-content-disp/04/draft-ietf-httpbis-content-disp-04.txt @ 1197

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

draft-ietf-httpbis-content-disp-04

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 27.1 KB
Line 
1
2
3
4HTTPbis Working Group                                         J. Reschke
5Internet-Draft                                                greenbytes
6Updates: 2616 (if approved)                            November 12, 2010
7Intended status: Standards Track
8Expires: May 16, 2011
9
10
11           Use of the Content-Disposition Header Field in the
12                   Hypertext Transfer Protocol (HTTP)
13                   draft-ietf-httpbis-content-disp-04
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.8.
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 May 16, 2011                  [Page 1]
56
57Internet-Draft         Content-Disposition in HTTP         November 2010
58
59
60   This Internet-Draft will expire on May 16, 2011.
61
62Copyright Notice
63
64   Copyright (c) 2010 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 May 16, 2011                  [Page 2]
112
113Internet-Draft         Content-Disposition in HTTP         November 2010
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119   2.  Notational Conventions . . . . . . . . . . . . . . . . . . . .  4
120   3.  Header Field Definition  . . . . . . . . . . . . . . . . . . .  4
121     3.1.  Grammar  . . . . . . . . . . . . . . . . . . . . . . . . .  5
122     3.2.  Disposition Type . . . . . . . . . . . . . . . . . . . . .  5
123     3.3.  Disposition Parameter: 'Filename'  . . . . . . . . . . . .  6
124     3.4.  Disposition Parameter: Extensions  . . . . . . . . . . . .  7
125     3.5.  Extensibility  . . . . . . . . . . . . . . . . . . . . . .  7
126   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
127   5.  Internationalization Considerations  . . . . . . . . . . . . .  8
128   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
129   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
130     7.1.  Registry for Disposition Values and Parameter  . . . . . .  8
131     7.2.  Header Field Registration  . . . . . . . . . . . . . . . .  9
132   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
133   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
134     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
135     9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
136   Appendix A.  Changes from the RFC 2616 Definition  . . . . . . . . 10
137   Appendix B.  Differences compared to RFC 2183  . . . . . . . . . . 11
138   Appendix C.  Alternative Approaches to Internationalization  . . . 11
139     C.1.  RFC 2047 Encoding  . . . . . . . . . . . . . . . . . . . . 11
140     C.2.  Percent Encoding . . . . . . . . . . . . . . . . . . . . . 11
141     C.3.  Encoding Sniffing  . . . . . . . . . . . . . . . . . . . . 12
142     C.4.  Implementations (to be removed by RFC Editor before
143           publication) . . . . . . . . . . . . . . . . . . . . . . . 12
144   Appendix D.  Change Log (to be removed by RFC Editor before
145                publication)  . . . . . . . . . . . . . . . . . . . . 12
146     D.1.  Since draft-reschke-rfc2183-in-http-00 . . . . . . . . . . 13
147     D.2.  Since draft-reschke-rfc2183-in-http-01 . . . . . . . . . . 13
148     D.3.  Since draft-reschke-rfc2183-in-http-02 . . . . . . . . . . 13
149     D.4.  Since draft-reschke-rfc2183-in-http-03 . . . . . . . . . . 13
150     D.5.  Since draft-ietf-httpbis-content-disp-00 . . . . . . . . . 13
151     D.6.  Since draft-ietf-httpbis-content-disp-01 . . . . . . . . . 13
152     D.7.  Since draft-ietf-httpbis-content-disp-02 . . . . . . . . . 13
153     D.8.  Since draft-ietf-httpbis-content-disp-03 . . . . . . . . . 14
154   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
155
156
157
158
159
160
161
162
163
164
165
166
167Reschke                   Expires May 16, 2011                  [Page 3]
168
169Internet-Draft         Content-Disposition in HTTP         November 2010
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.  Header Field Definition
204
205   The Content-Disposition response header field is used to convey
206   additional information about how to process the response payload, and
207   also can be used to attach additional metadata, such as the filename
208   to use when saving the response payload locally.
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223Reschke                   Expires May 16, 2011                  [Page 4]
224
225Internet-Draft         Content-Disposition in HTTP         November 2010
226
227
2283.1.  Grammar
229
230     content-disposition = "Content-Disposition" ":"
231                            disposition-type *( ";" disposition-parm )
232
233     disposition-type    = "inline" | "attachment" | disp-ext-type
234                         ; case-insensitive
235     disp-ext-type       = token
236
237     disposition-parm    = filename-parm | disp-ext-parm
238
239     filename-parm       = "filename" "=" value
240                         | "filename*" "=" ext-value
241
242     disp-ext-parm       = token "=" value
243                         | ext-token "=" ext-value
244     ext-token           = <the characters in token, followed by "*">
245
246   Defined in [RFC2616]:
247
248     token         = <token, defined in [RFC2616], Section 2.2>
249     quoted-string = <quoted-string, defined in [RFC2616], Section 2.2>
250     value         = <value, defined in [RFC2616], Section 3.6>
251                   ; token | quoted-string
252
253
254   Defined in [RFC5987]:
255
256     ext-value   = <ext-value, defined in [RFC5987], Section 3.2>
257
258   Senders MUST NOT generate header field values with multiple instances
259   of the same parameter name.  Recipients SHOULD treat these values as
260   invalid.
261
262   Note that due to the rules for implied linear whitespace (Section 2.1
263   of [RFC2616]), OPTIONAL whitespace can appear between words (token or
264   quoted-string) and separator characters.
265
266   Furthermore note that the format used for ext-value allows specifying
267   a natural language; this is of limited use for filenames and is
268   likely to be ignored by recipients.
269
2703.2.  Disposition Type
271
272   If the disposition type matches "attachment" (case-insensitively),
273   this indicates that the user agent should prompt the user to save the
274   response locally, rather than process it normally (as per its media
275   type).
276
277
278
279Reschke                   Expires May 16, 2011                  [Page 5]
280
281Internet-Draft         Content-Disposition in HTTP         November 2010
282
283
284   On the other hand, if it matches "inline" (case-insensitively), this
285   implies default processing.
286
287   Unknown or unhandled disposition types SHOULD be handled the same way
288   as "attachment" (see also [RFC2183], Section 2.8).
289
2903.3.  Disposition Parameter: 'Filename'
291
292   The parameters "filename" and "filename*", to be matched case-
293   insensitively, provide information on how to construct a filename for
294   storing the message payload.
295
296   Depending on the disposition type, this information might be used
297   right away (in the "save as..." interaction caused for the
298   "attachment" disposition type), or later on (for instance, when the
299   user decides to save the contents of the current page being
300   displayed).
301
302   The parameters "filename" and "filename*" differ only in that
303   "filename*" uses the encoding defined in [RFC5987], allowing the use
304   of characters not present in the ISO-8859-1 character set
305   ([ISO-8859-1]).
306
307   Many user agent implementations predating this specification do not
308   understand the "filename*" parameter.  Therefore, when both
309   "filename" and "filename*" are present in a single header field
310   value, recipients SHOULD pick "filename*" and ignore "filename".
311   This way, senders can avoid special-casing specific user agents by
312   sending both the more expressive "filename*" parameter, and the
313   "filename" parameter as fallback for legacy recipients (see Section 4
314   for an example).
315
316   It is essential that user agents treat the specified filename as
317   advisory only, thus be very careful in extracting the desired
318   information.  In particular:
319
320   o  When the value contains path separator characters, all but the
321      last segment SHOULD be ignored.  This prevents unintentional
322      overwriting of well-known file system location (such as "/etc/
323      passwd").
324
325   o  Many platforms do not use Internet Media Types ([RFC2046]) to hold
326      type information in the file system, but rely on filename
327      extensions instead.  Trusting the server-provided file extension
328      could introduce a privilege escalation when the saved file is
329      later opened (consider ".exe").  Thus, recipients need to ensure
330      that a file extension is used that is safe, optimally matching the
331      media type of the received payload.
332
333
334
335Reschke                   Expires May 16, 2011                  [Page 6]
336
337Internet-Draft         Content-Disposition in HTTP         November 2010
338
339
340   o  Recipients are advised to strip or replace character sequences
341      that are known to cause confusion both in user interfaces and in
342      filenames, such as control characters and leading and trailing
343      whitespace.
344
345   o  Other aspects recipients need to be aware of are names that have a
346      special meaning in the file system or in shell commands, such as
347      "." and "..", "~", "|", and also device names.
348
349      Note: Many user agents do not properly handle escape characters
350      when using the quoted-string form.  Furthermore, some user agents
351      erroneously try to perform unescaping of "percent" escapes (see
352      Appendix C.2), and thus might misinterpret filenames containing
353      the percent character followed by two hex digits.
354
3553.4.  Disposition Parameter: Extensions
356
357   To enable future extensions, unknown parameters SHOULD be ignored
358   (see also [RFC2183], Section 2.8).
359
3603.5.  Extensibility
361
362   Note that Section 9 of [RFC2183] defines IANA registries both for
363   disposition types and disposition parameters.  This registry is
364   shared by different protocols using Content-Disposition, such as MIME
365   and HTTP.  Therefore, not all registered values may make sense in the
366   context of HTTP.
367
3684.  Examples
369
370   Direct UA to show "save as" dialog, with a filename of
371   "example.html":
372
373   Content-Disposition: Attachment; filename=example.html
374
375   Direct UA to behave as if the Content-Disposition header field wasn't
376   present, but to remember the filename "an example.html" for a
377   subsequent save operation:
378
379     Content-Disposition: INLINE; FILENAME= "an example.html"
380
381   Note: this uses the quoted-string form so that the space character
382   can be included.
383
384
385
386
387
388
389
390
391Reschke                   Expires May 16, 2011                  [Page 7]
392
393Internet-Draft         Content-Disposition in HTTP         November 2010
394
395
396   Direct UA to show "save as" dialog, with a filename containing the
397   Unicode character U+20AC (EURO SIGN):
398
399     Content-Disposition: attachment;
400                          filename*= UTF-8''%e2%82%ac%20rates
401
402   Here, the encoding defined in [RFC5987] is also used to encode the
403   non-ISO-8859-1 character.
404
405   Same as above, but adding the "filename" parameter for compatibility
406   with user agents not implementing RFC 5987:
407
408     Content-Disposition: attachment;
409                          filename="EURO rates";
410                          filename*=utf-8''%e2%82%ac%20rates
411
412   Note: as of November 2010, those user agents that do not support the
413   RFC 5987 encoding ignore "filename*" when it occurs after "filename".
414   Unfortunately, some user agents that do support RFC 5987 do pick the
415   "filename" rather than the "filename*" parameter when it occurs
416   first; it is expected that this situation is going to improve soon.
417
4185.  Internationalization Considerations
419
420   The "filename*" parameter (Section 3.3), using the encoding defined
421   in [RFC5987], allows the server to transmit characters outside the
422   ISO-8859-1 character set, and also to optionally specify the language
423   in use.
424
425   Future parameters might also require internationalization, in which
426   case the same encoding can be used.
427
4286.  Security Considerations
429
430   Using server-supplied information for constructing local filenames
431   introduces many risks.  These are summarized in Section 3.3.
432
433   Furthermore, implementers also ought to be aware of the Security
434   Considerations applying to HTTP (see Section 15 of [RFC2616]), and
435   also the parameter encoding defined in [RFC5987] (see Section 5).
436
4377.  IANA Considerations
438
4397.1.  Registry for Disposition Values and Parameter
440
441   This specification does not introduce any changes to the registration
442   procedures for disposition values and parameters that are defined in
443   Section 9 of [RFC2183].
444
445
446
447Reschke                   Expires May 16, 2011                  [Page 8]
448
449Internet-Draft         Content-Disposition in HTTP         November 2010
450
451
4527.2.  Header Field Registration
453
454   This document updates the definition of the Content-Disposition HTTP
455   header field in the permanent HTTP header field registry (see
456   [RFC3864]).
457
458   Header field name:  Content-Disposition
459
460   Applicable protocol:  http
461
462   Status:  standard
463
464   Author/Change controller:  IETF
465
466   Specification document:  this specification (Section 3)
467
4688.  Acknowledgements
469
470   Thanks to Adam Barth, Rolf Eike Beer, Bjoern Hoehrmann, Alfred
471   Hoenes, Roar Lauritzsen, Henrik Nordstrom, and Mark Nottingham for
472   their valuable feedback.
473
4749.  References
475
4769.1.  Normative References
477
478   [ISO-8859-1]  International Organization for Standardization,
479                 "Information technology -- 8-bit single-byte coded
480                 graphic character sets -- Part 1: Latin alphabet No.
481                 1", ISO/IEC 8859-1:1998, 1998.
482
483   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
484                 Requirement Levels", BCP 14, RFC 2119, March 1997.
485
486   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
487                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
488                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
489
490   [RFC5987]     Reschke, J., "Character Set and Language Encoding for
491                 Hypertext Transfer Protocol (HTTP) Header Field
492                 Parameters", RFC 5987, August 2010.
493
4949.2.  Informative References
495
496   [RFC2046]     Freed, N. and N. Borenstein, "Multipurpose Internet
497                 Mail Extensions (MIME) Part Two: Media Types",
498                 RFC 2046, November 1996.
499
500
501
502
503Reschke                   Expires May 16, 2011                  [Page 9]
504
505Internet-Draft         Content-Disposition in HTTP         November 2010
506
507
508   [RFC2047]     Moore, K., "MIME (Multipurpose Internet Mail
509                 Extensions) Part Three: Message Header Extensions for
510                 Non-ASCII Text", RFC 2047, November 1996.
511
512   [RFC2183]     Troost, R., Dorner, S., and K. Moore, "Communicating
513                 Presentation Information in Internet Messages: The
514                 Content-Disposition Header Field", RFC 2183,
515                 August 1997.
516
517   [RFC2231]     Freed, N. and K. Moore, "MIME Parameter Value and
518                 Encoded Word Extensions: Character Sets, Languages, and
519                 Continuations", RFC 2231, November 1997.
520
521   [RFC2388]     Masinter, L., "Returning Values from Forms: multipart/
522                 form-data", RFC 2388, August 1998.
523
524   [RFC3864]     Klyne, G., Nottingham, M., and J. Mogul, "Registration
525                 Procedures for Message Header Fields", BCP 90,
526                 RFC 3864, September 2004.
527
528   [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
529                 "Uniform Resource Identifier (URI): Generic Syntax",
530                 STD 66, RFC 3986, January 2005.
531
532Appendix A.  Changes from the RFC 2616 Definition
533
534   Compared to Section 19.5.1 of [RFC2616], the following normative
535   changes reflecting actual implementations have been made:
536
537   o  According to RFC 2616, the disposition type "attachment" only
538      applies to content of type "application/octet-stream".  This
539      restriction has been removed, because user agents in practice do
540      not check the content type, and it also discourages properly
541      declaring the media type.
542
543   o  RFC 2616 only allows "quoted-string" for the filename parameter.
544      This would be an exceptional parameter syntax, and also doesn't
545      reflect actual use.
546
547   o  The definition for the disposition type "inline" ([RFC2183],
548      Section 2.1) has been re-added with a suggestion for its
549      processing.
550
551   o  This specification requires support for the extended parameter
552      encoding defined in [RFC5987].
553
554
555
556
557
558
559Reschke                   Expires May 16, 2011                 [Page 10]
560
561Internet-Draft         Content-Disposition in HTTP         November 2010
562
563
564Appendix B.  Differences compared to RFC 2183
565
566   Section 2 of [RFC2183] defines several additional disposition
567   parameters: "creation-date", "modification-date", "quoted-date-time",
568   and "size".  The majority of user agents does not implement these,
569   thus they have been omitted from this specification.
570
571Appendix C.  Alternative Approaches to Internationalization
572
573   By default, HTTP header field parameters cannot carry characters
574   outside the ISO-8859-1 ([ISO-8859-1]) character encoding (see
575   [RFC2616], Section 2.2).  For the "filename" parameter, this of
576   course is an unacceptable restriction.
577
578   Unfortunately, user agent implementers have not managed to come up
579   with an interoperable approach, although the IETF Standards Track
580   specifies exactly one solution ([RFC2231], clarified and profiled for
581   HTTP in [RFC5987]).
582
583   For completeness, the sections below describe the various approaches
584   that have been tried, and explains how they are inferior to the RFC
585   5987 encoding used in this specification.
586
587C.1.  RFC 2047 Encoding
588
589   RFC 2047 defines an encoding mechanism for header fields, but this
590   encoding is not supposed to be used for header field parameters - see
591   Section 5 of [RFC2047]:
592
593      An 'encoded-word' MUST NOT appear within a 'quoted-string'.
594
595      ...
596
597      An 'encoded-word' MUST NOT be used in parameter of a MIME Content-
598      Type or Content-Disposition field, or in any structured field body
599      except within a 'comment' or 'phrase'.
600
601   In practice, some user agents implement the encoding, some do not
602   (exposing the encoded string to the user), and some get confused by
603   it.
604
605C.2.  Percent Encoding
606
607   Some user agents accept percent encoded ([RFC3986], Section 2.1)
608   sequences of characters.  The character encoding being used for
609   decoding depends on various factors, including the encoding of the
610   referring page, the user agent's locale, its configuration, and also
611   the actual value of the parameter.
612
613
614
615Reschke                   Expires May 16, 2011                 [Page 11]
616
617Internet-Draft         Content-Disposition in HTTP         November 2010
618
619
620   In practice, this is hard to use because those user agents that do
621   not support it will display the escaped character sequence to the
622   user.  For those user agents that do implement this it is difficult
623   to predict what character encoding they actually expect.
624
625C.3.  Encoding Sniffing
626
627   Some user agents inspect the value (which defaults to ISO-8859-1 for
628   the quoted-string form) and switch to UTF-8 when it seems to be more
629   likely to be the correct interpretation.
630
631   As with the approaches above, this is not interoperable and
632   furthermore risks misinterpreting the actual value.
633
634C.4.  Implementations (to be removed by RFC Editor before publication)
635
636   Unfortunately, as of November 2010, neither the encoding defined in
637   RFCs 2231 and 5987, nor any of the alternate approaches discussed
638   above was implemented interoperably.  Thus, this specification
639   recommends the approach defined in RFC 5987, which at least has the
640   advantage of actually being specified properly.
641
642   The table below shows the implementation support for the various
643   approaches:
644
645   +---------------+------------+--------+--------------+--------------+
646   | User Agent    | RFC        | RFC    | Percent      | Encoding     |
647   |               | 2231/5987  | 2047   | Encoding     | Sniffing     |
648   +---------------+------------+--------+--------------+--------------+
649   | Chrome        | no (*)     | yes    | yes          | yes          |
650   | Firefox       | yes (**)   | yes    | no           | yes          |
651   | Internet      | no         | no     | yes          | no           |
652   | Explorer      |            |        |              |              |
653   | Konqueror     | yes        | no     | no           | no           |
654   | Opera         | yes        | no     | no           | no           |
655   | Safari        | no         | no     | no           | yes          |
656   +---------------+------------+--------+--------------+--------------+
657
658   (*) But currently being implemented.
659
660   (**) Does not implement the fallback behavior to "filename" described
661   in Section 3.3.
662
663Appendix D.  Change Log (to be removed by RFC Editor before publication)
664
665   Note: the issues names in the change log entries for
666   draft-reschke-rfc2183-in-http refer to <http://greenbytes.de/tech/
667   webdav/draft-reschke-rfc2183-in-http-issues.html>.
668
669
670
671Reschke                   Expires May 16, 2011                 [Page 12]
672
673Internet-Draft         Content-Disposition in HTTP         November 2010
674
675
676D.1.  Since draft-reschke-rfc2183-in-http-00
677
678   Adjust terminology ("header" -> "header field").  Update rfc2231-in-
679   http reference.
680
681D.2.  Since draft-reschke-rfc2183-in-http-01
682
683   Update rfc2231-in-http reference.  Actually define the "filename"
684   parameter.  Add internationalization considerations.  Add examples
685   using the RFC 5987 encoding.  Add overview over other approaches,
686   plus a table reporting implementation status.  Add and resolve issue
687   "nodep2183".  Add issues "asciivsiso", "deplboth", "quoted", and
688   "registry".
689
690D.3.  Since draft-reschke-rfc2183-in-http-02
691
692   Add and close issue "docfallback".  Close issues "asciivsiso",
693   "deplboth", "quoted", and "registry".
694
695D.4.  Since draft-reschke-rfc2183-in-http-03
696
697   Updated to be a Working Draft of the IETF HTTPbis Working Group.
698
699D.5.  Since draft-ietf-httpbis-content-disp-00
700
701   Closed issues:
702
703   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/242>: "handling of
704      unknown disposition types"
705
706   Slightly updated the notes about the proposed fallback behavior.
707
708D.6.  Since draft-ietf-httpbis-content-disp-01
709
710   Various editorial improvements.
711
712D.7.  Since draft-ietf-httpbis-content-disp-02
713
714   Closed issues:
715
716   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/244>: "state that
717      repeating parameters are invalid"
718
719   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/245>: "warn about
720      %xx in filenames being misinterpreted"
721
722   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/246>: "mention
723      control chars when talking about postprecessing the filename
724
725
726
727Reschke                   Expires May 16, 2011                 [Page 13]
728
729Internet-Draft         Content-Disposition in HTTP         November 2010
730
731
732      parameter"
733
734   Update Appendix C.4; Opera 10.63 RC implements the recommended
735   fallback behavior.
736
737D.8.  Since draft-ietf-httpbis-content-disp-03
738
739   Closed issues:
740
741   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/252>:
742      "'modification-date' *is* implemented in Konq 4.5"
743
744   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/253>: "clarify what
745      LWS means for the Content-Disp grammar"
746
747   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/258>: "Avoid passive
748      voice in message requirements"
749
750   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/263>: "text about
751      historical percent-decoding unclear"
752
753   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/264>: "add
754      explanation of language tagging"
755
756   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/265>: "Clarify that
757      C-D spec does not apply to multipart upload"
758
759Index
760
761   C
762      Content-Disposition header  4
763
764   H
765      Headers
766         Content-Disposition  4
767
768Author's Address
769
770   Julian F. Reschke
771   greenbytes GmbH
772   Hafenweg 16
773   Muenster, NW  48155
774   Germany
775
776   EMail: julian.reschke@greenbytes.de
777   URI:   http://greenbytes.de/tech/webdav/
778
779
780
781
782
783Reschke                   Expires May 16, 2011                 [Page 14]
784
Note: See TracBrowser for help on using the repository browser.