source: draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.xml @ 1296

Last change on this file since 1296 was 1296, checked in by julian.reschke@…, 9 years ago

there's no index PI

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 41.4 KB
Line 
1<?xml version="1.0" encoding="utf-8"?>
2<?xml-stylesheet type='text/xsl' href='../../draft-ietf-httpbis/myxml2rfc.xslt' ?>
3<?rfc toc="yes"?>
4<?rfc symrefs="yes"?>
5<?rfc sortrefs="yes"?>
6<?rfc compact="yes"?>
7<?rfc comments="yes"?>
8<?rfc inline="yes"?>
9<?rfc subcompact="no"?>
10<?rfc rfcedstyle="yes"?>
11<?rfc-ext allow-markup-in-artwork="yes" ?>
12<?rfc-ext include-references-in-index="yes" ?>
13
14<!DOCTYPE rfc [
15  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
16  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
17  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
18  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
19  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
20  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
21  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
22  <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
23  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
24  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
25  <!ENTITY mdash "&#8212;">
26  <!ENTITY nbsp  "&#160;">
27  <!ENTITY nbhy  "&#8209;">
28]>
29
30<rfc xmlns:x="http://purl.org/net/xml2rfc/ext" xmlns:ed="http://greenbytes.de/2002/rfcedit" ipr="trust200902" docName="draft-ietf-httpbis-content-disp-latest" category="std" x:maturity-level="proposed" xml:lang="en" updates="2616">
31        <front>
32  <title abbrev="Content-Disposition in HTTP">Use of the Content-Disposition&nbsp;Header&nbsp;Field
33  in the Hypertext&nbsp;Transfer&nbsp;Protocol&nbsp;(HTTP)</title>
34  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
35    <organization abbrev="greenbytes">greenbytes GmbH</organization>
36    <address>
37      <postal>
38        <street>Hafenweg 16</street>
39        <city>Muenster</city><region>NW</region><code>48155</code>
40        <country>Germany</country>
41      </postal>
42      <email>julian.reschke@greenbytes.de</email>       
43      <uri>http://greenbytes.de/tech/webdav/</uri>     
44    </address>
45  </author>
46
47  <date month="May" year="2011"/>
48  <workgroup>HTTPbis Working Group</workgroup>
49 
50  <keyword>HTTP</keyword>
51  <keyword>Hypertext Transfer Protocol</keyword>
52  <keyword>Content-Disposition</keyword>
53  <keyword>filename</keyword>
54  <keyword>attachment</keyword>
55  <keyword>inline</keyword>
56
57  <abstract>
58    <t>
59      RFC 2616 defines the Content-Disposition response header field,
60      but points out that it is not part of the HTTP/1.1 Standard.
61      This specification takes over the definition and registration of
62      Content-Disposition, as used in HTTP, and clarifies internationalization
63      aspects.
64    </t>
65  </abstract>
66<!-- 
67  <note title="Editorial Note (To be removed by RFC Editor before publication)">
68    <t>
69      This specification is expected to replace the definition of Content-Disposition
70      in the HTTP/1.1 specification, as currently revised by the IETF HTTPbis
71      working group. See also <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/123"/>.
72    </t>
73    <t>
74      Discussion of this draft should take place on the HTTPBIS working group
75      mailing list (ietf-http-wg@w3.org). The current issues list is
76      at <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/query?component=content-disp"/>
77      and related documents (including fancy diffs) can be found at
78      <eref target="http://tools.ietf.org/wg/httpbis/"/>.
79    </t>
80    <t>
81      The changes in this draft are summarized in <xref target="changes.since.09"/>.
82    </t>
83  </note>
84-->
85  </front>
86  <middle>
87
88<section title="Introduction" anchor="introduction">
89<t>
90  RFC 2616 defines the Content-Disposition response header field
91  (<xref target="RFC2616" x:fmt="of" x:sec="19.5.1"/>)
92  but points out that it is not part of the HTTP/1.1 Standard (<xref target="RFC2616" x:fmt="sec" x:sec="15.5"/>):
93</t>
94<x:blockquote cite="http://tools.ietf.org/html/rfc2616#section-15.5">
95  <t>
96    Content-Disposition is not part of the HTTP standard, but since it is
97    widely implemented, we are documenting its use and risks for implementers.
98  </t>
99</x:blockquote>
100<t>
101  This specification takes over the definition and registration of
102  Content-Disposition, as used in HTTP.
103  Based on interoperability testing with existing user agents (UAs),
104  it fully defines a profile of the
105  features defined in the Multipurpose Internet Mail Extensions (MIME) variant (<xref target="RFC2183"/>) of the
106  header field, and also clarifies internationalization
107  aspects.
108</t>
109<x:note>
110  <t>
111    <x:h>Note:</x:h> This document does not apply to Content-Disposition
112    header fields appearing in payload bodies transmitted over HTTP, such as
113    when using the media type "multipart/form-data" (<xref target="RFC2388"/>).
114  </t>
115</x:note>
116</section> 
117
118<section title="Notational Conventions" anchor="notational.conventions">
119<t>
120  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
121  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
122  are to be interpreted as described in <xref target="RFC2119"/>.
123</t>
124<t>
125  This specification uses the augmented BNF (ABNF) notation defined in
126  <xref target="RFC2616" x:fmt="of" x:sec="2.1"/>, including its rules for
127  implied linear whitespace (LWS).
128</t>
129</section>
130
131<section title="Conformance and Error Handling" anchor="conformance.and.error.handling">
132<t>
133  This specification defines conformance criteria for both senders (usually,
134  HTTP origin servers) and recipients (usually, HTTP user agents) of the
135  Content-Disposition header field. An implementation is considered conformant if
136  it complies with all of the requirements associated with its role.
137</t>
138<t>
139  This specification also defines certain forms of the header field-value to be
140  invalid, using both ABNF and prose requirements (<xref target="header.field.definition"/>),
141  but it does not define special handling of these invalid field-values.
142</t>
143<t>
144  Senders &MUST-NOT; generate Content-Disposition header fields that are
145  invalid.
146</t>
147<t>
148  Recipients &MAY; take steps to recover a usable field-value
149  from an invalid header field, but &SHOULD-NOT; reject the message outright,
150  unless this is explicitly desirable behavior (e.g., the implementation is a
151  validator). As such, the default handling of invalid fields is to ignore them.
152</t>
153</section>
154
155<section title="Header Field Definition" anchor="header.field.definition">
156  <iref item="Header Fields" subitem="Content-Disposition" primary="true" x:for-anchor=""/>
157  <iref item="Content-Disposition header field" primary="true" x:for-anchor=""/>
158<t>
159  The Content-Disposition response header field is used to convey additional
160  information about how to process the response payload, and also can be used
161  to attach additional metadata, such as the filename to use when saving the
162  response payload locally.
163</t>
164
165<section title="Grammar">
166<figure><artwork type="abnf2616">
167  content-disposition = "Content-Disposition" ":"
168                         disposition-type *( ";" disposition-parm )
169
170  disposition-type    = "inline" | "attachment" | disp-ext-type
171                      ; case-insensitive
172  disp-ext-type       = token
173
174  disposition-parm    = filename-parm | disp-ext-parm
175
176  filename-parm       = "filename" "=" value
177                      | "filename*" "=" ext-value
178 
179  disp-ext-parm       = token "=" value
180                      | ext-token "=" ext-value
181  ext-token           = &lt;the characters in token, followed by "*"&gt;
182</artwork></figure>
183
184<figure>
185<preamble>Defined in <xref target="RFC2616"/>:</preamble>
186<artwork type="abnf2616">
187  token         = &lt;token, defined in <xref target="RFC2616" x:fmt="," x:sec="2.2"/>&gt;
188  quoted-string = &lt;quoted-string, defined in <xref target="RFC2616" x:fmt="," x:sec="2.2"/>&gt;
189  value         = &lt;value, defined in <xref target="RFC2616" x:fmt="," x:sec="3.6"/>&gt;
190                ; token | quoted-string
191             
192</artwork></figure>
193<figure>
194<preamble>Defined in <xref target="RFC5987"/>:</preamble>
195<artwork type="abnf2616">
196  ext-value   = &lt;ext-value, defined in <xref target="RFC5987" x:sec="3.2"/>&gt;
197</artwork></figure>
198<t>
199  Content-Disposition header field values with multiple instances of the same
200  parameter name are invalid.
201</t>
202<t>
203  Note that due to the rules for implied linear whitespace
204  (<xref target="RFC2616" x:fmt="of" x:sec="2.1"/>), &OPTIONAL; whitespace can
205  appear between words (token or quoted-string) and separator characters.
206</t>
207<t>
208  Furthermore, note that the format used for ext-value allows specifying a
209  natural language (e.g., "en"); this is of limited use for filenames and is
210  likely to be ignored by recipients.
211</t>
212</section>
213
214<section title="Disposition Type" anchor="disposition.type">
215<t>
216  If the disposition type matches "attachment" (case-insensitively), this
217  indicates that the recipient should prompt the user to save the response
218  locally, rather than process it normally (as per its media type).
219</t>
220<t>
221  On the other hand, if it matches "inline" (case-insensitively), this implies
222  default processing. Therefore, the disposition type "inline" is only useful
223  when it is augmented with additional parameters, such as the filename (see
224  below).
225</t>
226<t>
227  Unknown or unhandled disposition types &SHOULD; be handled by recipients the
228  same way as "attachment" (see also <xref target="RFC2183" x:fmt="," x:sec="2.8"/>).
229</t>
230</section>
231
232<section title="Disposition Parameter: 'Filename'" anchor="disposition.parameter.filename">
233<t>
234  The parameters "filename" and "filename*", to be matched case-insensitively,
235  provide information on how to construct a filename for storing the message
236  payload.
237</t>
238<t>
239  Depending on the disposition type, this information might be used right away
240  (in the "save as..." interaction caused for the "attachment" disposition type),
241  or later on (for instance, when the user decides to save the contents of the
242  current page being displayed).
243</t>
244<t>
245  The parameters "filename" and "filename*" differ only in that "filename*" uses
246  the encoding defined in <xref target="RFC5987"/>, allowing the use
247  of characters not present in the ISO-8859-1 character set (<xref target="ISO-8859-1"/>).
248</t>
249<t>
250  Many user agent implementations predating this specification
251  do not understand the "filename*" parameter. Therefore, when both "filename"
252  and "filename*" are present in a single header field value, recipients
253  &SHOULD; pick "filename*" and ignore "filename". This way, senders
254  can avoid special-casing specific user agents by sending both the
255  more expressive "filename*" parameter, and the "filename" parameter
256  as fallback for legacy recipients (see <xref target="examples"/> for
257  an example).
258</t>
259<t>
260  It is essential that recipients treat the specified filename as advisory
261  only, and thus be very careful in extracting the desired information.
262  In particular:
263  <list style="symbols">
264    <x:lt><t>
265      Recipients &MUST-NOT; be able to write into any location other than one
266      to which they are specifically entitled. To illustrate the problem,
267      consider the consequences of being able to overwrite well-known system
268      locations (such as "/etc/passwd"). One strategy to achieve this is to
269      never trust folder name information in the filename parameter, for
270      instance by stripping all but the last path segment and only considering
271      the actual filename (where 'path segment' are the components of the field
272      value delimited by the path separator characters "\" and "/").
273    </t></x:lt>
274    <x:lt><t>
275      Many platforms do not use Internet Media Types (<xref target="RFC2046"/>)
276      to hold type information in the file system, but rely on filename
277      extensions instead. Trusting the server-provided file extension could
278      introduce a privilege escalation when the saved file is later opened
279      (consider ".exe"). Thus, recipients that make use of file extensions
280      to determine the media type &MUST; ensure that a file extension
281      is used that is safe, optimally matching the media type of the received
282      payload.
283    </t></x:lt>
284    <x:lt><t>
285      Recipients &SHOULD; strip or replace character sequences that are
286      known to cause confusion both in user interfaces and in filenames, such as
287      control characters and leading and trailing whitespace.
288    </t></x:lt>
289    <x:lt><t>
290      Other aspects recipients need to be aware of are names that have a
291      special meaning in the file system or in shell commands, such as "." and "..",
292      "~", "|", and also device names. Recipients &SHOULD; ignore or substitute
293      names like these.
294    </t></x:lt>
295  </list>
296</t>
297<x:note>
298  <t>
299    <x:h>Note:</x:h> Many user agents do not properly handle the escape
300    character "\" when using the quoted-string form. Furthermore, some user agents
301    erroneously try to perform unescaping of "percent" escapes (see
302    <xref target="alternatives.percent"/>), and thus might misinterpret
303    filenames containing the percent character followed by two hex digits.
304  </t>
305</x:note>
306</section>
307
308<section title="Disposition Parameter: Extensions" anchor="disposition.parameter.extensions">
309<t>
310  To enable future extensions, recipients &SHOULD; ignore unrecognized
311  parameters (see also <xref target="RFC2183" x:fmt="," x:sec="2.8"/>).
312</t>
313</section>
314
315<section title="Extensibility" anchor="extensibility">
316<t>
317  Note that <xref target="RFC2183" x:fmt="of" x:sec="9"/> defines IANA registries both
318  for disposition types and disposition parameters. This registry is
319  shared by different protocols using Content-Disposition, such as MIME and HTTP.
320  Therefore, not all registered values may make sense in the context of HTTP.
321</t>
322</section>
323
324</section> 
325
326<section title="Examples" anchor="examples">
327
328<figure>
329<preamble>
330Direct the UA to show "save as" dialog, with a filename of "example.html": 
331</preamble>
332<artwork type="example">
333Content-Disposition: Attachment; filename=example.html
334</artwork></figure>
335<figure>
336<preamble>
337Direct the UA to behave as if the Content-Disposition header field wasn't present,
338but to remember the filename "an example.html" for a subsequent save operation:
339</preamble>
340<artwork type="example" x:indent-with="  ">
341Content-Disposition: INLINE; FILENAME= "an example.html"
342</artwork>
343<postamble>
344  Note: This uses the quoted-string form so that the space character
345  can be included.
346</postamble>
347</figure>
348<figure>
349<preamble>
350Direct the UA to show "save as" dialog, with a filename containing the Unicode character  U+20AC (EURO SIGN):
351</preamble>
352<artwork type="example" x:indent-with="  ">
353Content-Disposition: attachment;
354                     filename*= UTF-8''<x:highlight>%e2%82%ac</x:highlight>%20rates
355</artwork>
356<postamble>
357  Here, the encoding defined in <xref target="RFC5987"/> is also used to encode the
358  non-ISO-8859-1 character.
359</postamble>
360</figure>
361<figure>
362<preamble>
363This example is the same as above, but adding the "filename" parameter for
364compatibility with user agents not implementing RFC 5987:
365</preamble>
366<artwork type="example" x:indent-with="  ">
367Content-Disposition: attachment;
368                     filename="EURO rates";
369                     filename*=utf-8''<x:highlight>%e2%82%ac</x:highlight>%20rates
370</artwork>
371<postamble>
372  Note: Those user agents that do not support the RFC 5987 encoding ignore
373  "filename*" when it occurs after "filename".
374</postamble>
375</figure>
376
377</section>
378
379<section title="Internationalization Considerations" anchor="i18n">
380<t>
381  The "filename*" parameter (<xref target="disposition.parameter.filename"/>),
382  using the encoding defined in <xref target="RFC5987"/>, allows the
383  server to transmit characters outside the ISO-8859-1 character set,
384  and also to optionally specify the language in use.
385</t>
386<t>
387  Future parameters might also require internationalization, in which case
388  the same encoding can be used.
389</t>
390</section>
391
392<section title="Security Considerations" anchor="security.considerations">
393<t>
394  Using server-supplied information for constructing local filenames introduces
395  many risks. These are summarized in <xref target="disposition.parameter.filename"/>.
396</t>
397<t>
398  Furthermore, implementers ought to be aware of the security considerations
399  applying to HTTP (see <xref target="RFC2616" x:fmt="of" x:sec="15"/>), and also the parameter encoding defined in <xref target="RFC5987"/>
400  (see <xref target="RFC5987" x:fmt="sec" x:sec="5"/>).
401</t>
402</section> 
403
404<section title="IANA Considerations" anchor="iana.considerations">
405
406<section title="Registry for Disposition Values and Parameters" anchor="registry">
407<t>
408  This specification does not introduce any changes to the registration
409  procedures for disposition values and parameters that are defined in
410  <xref target="RFC2183" x:fmt="of" x:sec="9"/>.
411</t>
412</section>
413
414<section title="Header Field Registration" anchor="header.field.registration"> 
415<t>
416  This document updates the definition of the Content-Disposition HTTP header field
417  in the permanent HTTP header field registry (see <xref target="RFC3864"/>).
418</t>
419<t>
420<list style="hanging">
421  <t hangText="Header field name:">Content-Disposition</t>
422  <t hangText="Applicable protocol:">http</t>
423  <t hangText="Status:">standard</t>
424  <t hangText="Author/Change controller:">IETF</t>
425  <t hangText="Specification document:">this specification (<xref target="header.field.definition"/>)</t>
426  <t hangText="Related information:">none</t>
427</list>
428</t>
429</section>
430
431</section> 
432
433<section title="Acknowledgements">
434<t>
435  Thanks to
436  Adam Barth,
437  Rolf Eike Beer,
438  Stewart Bryant,
439  Bjoern Hoehrmann,
440  Alfred Hoenes,
441  Roar Lauritzsen,
442  Alexey Melnikov,
443  Henrik Nordstrom, and
444  Mark Nottingham for
445  their valuable feedback.
446</t>
447</section> 
448
449  </middle>
450  <back>
451 
452<references title="Normative References">
453 
454  <reference anchor="RFC2119">
455    <front>
456      <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
457      <author initials="S." surname="Bradner" fullname="Scott Bradner">
458        <organization>Harvard University</organization>
459        <address><email>sob@harvard.edu</email></address>
460      </author>
461      <date month="March" year="1997"/>
462      <area>General</area>
463      <keyword>keyword</keyword>
464    </front>
465    <seriesInfo name="BCP" value="14"/>
466    <seriesInfo name="RFC" value="2119"/>
467  </reference>
468
469  <reference anchor="RFC2616">
470    <front>
471      <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
472      <author initials="R." surname="Fielding" fullname="R. Fielding">
473        <organization>University of California, Irvine</organization>
474        <address><email>fielding@ics.uci.edu</email></address>
475      </author>
476      <author initials="J." surname="Gettys" fullname="J. Gettys">
477        <organization>W3C</organization>
478        <address><email>jg@w3.org</email></address>
479      </author>
480      <author initials="J." surname="Mogul" fullname="J. Mogul">
481        <organization>Compaq Computer Corporation</organization>
482        <address><email>mogul@wrl.dec.com</email></address>
483      </author>
484      <author initials="H." surname="Frystyk" fullname="H. Frystyk">
485        <organization>MIT Laboratory for Computer Science</organization>
486        <address><email>frystyk@w3.org</email></address>
487      </author>
488      <author initials="L." surname="Masinter" fullname="L. Masinter">
489        <organization>Xerox Corporation</organization>
490        <address><email>masinter@parc.xerox.com</email></address>
491      </author>
492      <author initials="P." surname="Leach" fullname="P. Leach">
493        <organization>Microsoft Corporation</organization>
494        <address><email>paulle@microsoft.com</email></address>
495      </author>
496      <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
497        <organization>W3C</organization>
498        <address><email>timbl@w3.org</email></address>
499      </author>
500      <date month="June" year="1999"/>
501    </front>
502    <seriesInfo name="RFC" value="2616"/>
503  </reference>
504
505  <reference anchor="RFC5987">
506        <front>
507      <title>Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</title>
508      <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
509        <organization abbrev="greenbytes">greenbytes GmbH</organization>
510        <address>
511          <postal>
512            <street>Hafenweg 16</street>
513            <city>Muenster</city><region>NW</region><code>48155</code>
514            <country>Germany</country>
515          </postal>
516          <email>julian.reschke@greenbytes.de</email>   
517          <uri>http://greenbytes.de/tech/webdav/</uri> 
518        </address>
519      </author>
520      <date month="August" year="2010"/>
521    </front>
522    <seriesInfo name="RFC" value="5987"/>
523  </reference>
524
525  <reference anchor="ISO-8859-1">
526    <front>
527      <title>Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No.&nbsp;1</title>
528      <author>
529        <organization>International Organization for Standardization</organization>
530      </author>
531      <date year="1998"/>
532    </front>
533    <seriesInfo name="ISO/IEC" value="8859-1:1998"/>
534  </reference>
535
536</references>
537 
538<references title="Informative References">
539
540  <reference anchor="RFC2046">
541    <front>
542      <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
543      <author initials="N." surname="Freed" fullname="Ned Freed">
544        <organization>Innosoft International, Inc.</organization>
545        <address><email>ned@innosoft.com</email></address>
546      </author>
547      <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
548        <organization>First Virtual Holdings</organization>
549        <address><email>nsb@nsb.fv.com</email></address>
550      </author>
551      <date month="November" year="1996"/>
552    </front>
553    <seriesInfo name="RFC" value="2046"/>
554  </reference>
555
556  <reference anchor="RFC2047">
557    <front>
558      <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
559      <author initials="K." surname="Moore" fullname="Keith Moore">
560        <organization>University of Tennessee</organization>
561        <address><email>moore@cs.utk.edu</email></address>
562      </author>
563      <date month="November" year="1996"/>
564    </front>
565    <seriesInfo name="RFC" value="2047"/>
566  </reference>
567
568  <reference anchor="RFC2183">
569    <front>
570      <title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</title>
571      <author initials="R." surname="Troost" fullname="Rens Troost">
572        <organization>New Century Systems</organization>
573        <address><email>rens@century.com</email></address>
574      </author>
575      <author initials="S." surname="Dorner" fullname="Steve Dorner">
576        <organization>QUALCOMM Incorporated</organization>
577        <address><email>sdorner@qualcomm.com</email></address>
578      </author>
579      <author initials="K." surname="Moore" fullname="Keith Moore" role="editor">
580        <organization>Department of Computer Science</organization>
581        <address><email>moore@cs.utk.edu</email></address>
582      </author>
583      <date year="1997" month="August"/>
584    </front>
585    <seriesInfo name="RFC" value="2183"/>
586  </reference>
587
588  <reference anchor="RFC2231">
589    <front>
590      <title abbrev="MIME Value and Encoded Word Extensions">MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</title>
591      <author initials="N." surname="Freed" fullname="Ned Freed">
592        <organization abbrev="Innosoft">Innosoft International, Inc.</organization>
593        <address><email>ned.freed@innosoft.com</email></address>
594      </author>
595      <author initials="K." surname="Moore" fullname="Keith Moore">
596        <organization>University of Tennessee</organization>
597        <address><email>moore@cs.utk.edu</email></address>
598      </author>
599      <date year="1997" month="November"/>
600    </front>
601    <seriesInfo name="RFC" value="2231"/>
602  </reference>
603
604  <reference anchor="RFC2388">
605    <front>
606      <title abbrev="multipart/form-data">Returning Values from Forms: multipart/form-data</title>
607      <author initials="L." surname="Masinter" fullname="Larry Masinter">
608        <organization>Xerox Palo Alto Research Center</organization>
609        <address>
610          <email>masinter@parc.xerox.com</email>
611        </address>
612      </author>
613      <date year="1998" month="August"/>
614    </front>
615    <seriesInfo name="RFC" value="2388"/>
616  </reference>
617<!--
618  <reference anchor="RFC3629">
619    <front>
620      <title>UTF-8, a transformation format of ISO 10646</title>
621      <author initials="F." surname="Yergeau" fullname="F. Yergeau">
622        <organization>Alis Technologies</organization>
623        <address><email>fyergeau@alis.com</email></address>
624      </author>
625      <date month="November" year="2003"/>
626    </front>
627    <seriesInfo name="STD" value="63"/>
628    <seriesInfo name="RFC" value="3629"/>
629  </reference>-->
630
631  <reference anchor="RFC3864">
632    <front>
633      <title>Registration Procedures for Message Header Fields</title>
634      <author initials="G." surname="Klyne" fullname="G. Klyne">
635        <organization>Nine by Nine</organization>
636        <address><email>GK-IETF@ninebynine.org</email></address>
637      </author>
638      <author initials="M." surname="Nottingham" fullname="M. Nottingham">
639        <organization>BEA Systems</organization>
640        <address><email>mnot@pobox.com</email></address>
641      </author>
642      <author initials="J." surname="Mogul" fullname="J. Mogul">
643        <organization>HP Labs</organization>
644        <address><email>JeffMogul@acm.org</email></address>
645      </author>
646      <date year="2004" month="September"/>
647    </front>
648    <seriesInfo name="BCP" value="90"/>
649    <seriesInfo name="RFC" value="3864"/>
650  </reference>
651
652  <reference anchor="RFC3986">
653   <front>
654    <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
655    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
656      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
657      <address>
658         <email>timbl@w3.org</email>
659         <uri>http://www.w3.org/People/Berners-Lee/</uri>
660      </address>
661    </author>
662    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
663      <organization abbrev="Day Software">Day Software</organization>
664      <address>
665        <email>fielding@gbiv.com</email>
666        <uri>http://roy.gbiv.com/</uri>
667      </address>
668    </author>
669    <author initials="L." surname="Masinter" fullname="Larry Masinter">
670      <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
671      <address>
672        <email>LMM@acm.org</email>
673        <uri>http://larry.masinter.net/</uri>
674      </address>
675    </author>
676    <date month="January" year="2005"/>
677   </front>
678   <seriesInfo name="STD" value="66"/>
679   <seriesInfo name="RFC" value="3986"/>
680  </reference>
681
682   <reference anchor="US-ASCII">
683    <front>
684      <title>Coded Character Set -- 7-bit American Standard Code for Information Interchange</title>
685      <author>
686        <organization>American National Standards Institute</organization>
687      </author>
688      <date year="1986"/>
689    </front>
690    <seriesInfo name="ANSI" value="X3.4"/>
691   </reference>
692
693</references>
694
695<section title="Changes from the RFC 2616 Definition" anchor="changes.from.rfc2616">
696<t>
697  Compared to <xref target="RFC2616" x:fmt="of" x:sec="19.5.1"/>, the following
698  normative changes reflecting actual implementations have been made:
699<list style="symbols">
700  <t>
701    According to RFC 2616, the disposition type "attachment" only applies to
702    content of type "application/octet-stream". This restriction has been
703    removed, because recipients in practice do not check the content type, and
704    it also discourages properly declaring the media type.
705  </t>
706  <t>
707    RFC 2616 only allows "quoted-string" for the filename parameter. This
708    would be an exceptional parameter syntax, and also doesn't reflect actual
709    use.
710  </t>
711  <t>
712    The definition for the disposition type "inline" (<xref target="RFC2183" x:fmt="," x:sec="2.1"/>)
713    has been re-added with a suggestion for its processing.
714  </t>
715  <t>
716    This specification requires support for the extended parameter encoding
717    defined in <xref target="RFC5987"/>.
718  </t>
719</list>
720</t>
721</section>
722
723<section title="Differences Compared to RFC 2183" anchor="diffs.compared.to.rfc2183">
724<t>
725  <xref target="RFC2183" x:fmt="of" x:sec="2"/> defines several additional
726  disposition parameters: "creation-date", "modification-date",
727  "quoted-date-time", and "size". The majority of user agents do not implement
728  these; thus, they have been omitted from this specification.
729</t>
730</section>
731
732<section title="Alternative Approaches to Internationalization" anchor="alternatives">
733<t>
734  By default, HTTP header field parameters cannot carry characters outside
735  the ISO-8859-1 (<xref target="ISO-8859-1"/>) character encoding (see
736  <xref target="RFC2616" x:fmt="," x:sec="2.2"/>). For the "filename"
737  parameter, this of course is an unacceptable restriction.
738</t>
739<t>
740  Unfortunately, user agent implementers have not managed to come up with
741  an interoperable approach, although the IETF Standards Track specifies
742  exactly one solution (<xref target="RFC2231"/>, clarified and profiled for
743  HTTP in <xref target="RFC5987"/>).
744</t>
745<t>
746  For completeness, the sections below describe the various approaches that
747  have been tried, and explain how they are inferior to the RFC&nbsp;5987
748  encoding used in this specification.
749</t>
750
751<section title="RFC 2047 Encoding" anchor="alternatives.rfc2047">
752<t>
753  RFC 2047 defines an encoding mechanism for
754  header fields, but this encoding is not supposed to be used for
755  header field parameters &mdash; see <xref target="RFC2047" x:fmt="of" x:sec="5"/>: 
756</t>
757<x:blockquote cite="http://tools.ietf.org/html/rfc2047#section-5">
758  <t>
759    An 'encoded-word' MUST NOT appear within a 'quoted-string'.
760  </t>
761  <t>
762    ...
763  </t>
764  <t>
765    An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a 'comment' or 'phrase'.
766  </t>
767</x:blockquote>
768<t>
769  In practice, some user agents implement the encoding, some do not
770  (exposing the encoded string to the user), and some get confused by it.
771</t>
772</section>
773
774<section title="Percent Encoding" anchor="alternatives.percent">
775<t>
776  Some user agents accept percent-encoded (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>)
777  sequences of characters. The character encoding being used for decoding
778  depends on various factors, including the encoding of the referring page,
779  the user agent's locale, its configuration, and also the actual value of
780  the parameter.
781</t>
782<t>
783  In practice, this is hard to use because those user agents that do not
784  support it will display the escaped character sequence to the user. For those
785  user agents that do implement this, it is difficult to predict what character
786  encoding they actually expect.
787</t>
788</section>
789
790<section title="Encoding Sniffing" anchor="alternatives.sniff">
791<t>
792  Some user agents inspect the value (which defaults to ISO-8859-1 for the
793  quoted-string form) and switch to UTF-8 when it seems to be more likely to be
794  the correct interpretation.
795</t>
796<t>
797  As with the approaches above, this is not interoperable and, furthermore,
798  risks misinterpreting the actual value.
799</t>
800</section>
801
802<!--<section title="Implementations (to be removed by RFC Editor before publication)" anchor="alternatives.implementations">
803<t>
804  Unfortunately, as of March 2011, neither the encoding defined in RFCs 2231
805  and 5987, nor any of the alternate approaches discussed above was
806  implemented interoperably. Thus, this specification recommends the approach
807  defined in RFC 5987, which at least has the advantage of actually being
808  specified properly.
809</t>
810<t>
811  The table below shows the support for the various approaches in the current
812  implementations:
813</t>
814<texttable align="left">
815  <ttcol>User Agent</ttcol>
816  <ttcol>RFC 2231/5987</ttcol>
817  <ttcol>RFC 2047</ttcol>
818  <ttcol>Percent Encoding</ttcol>
819  <ttcol>Encoding Sniffing</ttcol>
820 
821  <c>Chrome</c>
822  <c>yes</c>
823  <c>yes</c>
824  <c>yes</c>
825  <c>yes</c>
826
827  <c>Firefox</c>
828  <c>yes (*)</c>
829  <c>yes</c>
830  <c>no</c>
831  <c>yes</c>
832
833  <c>Internet Explorer</c>
834  <c>yes (**)</c>
835  <c>no</c>
836  <c>yes</c>
837  <c>no</c>
838
839  <c>Konqueror</c>
840  <c>yes</c>
841  <c>no</c>
842  <c>no</c>
843  <c>no</c>
844
845  <c>Opera</c>
846  <c>yes</c>
847  <c>no</c>
848  <c>no</c>
849  <c>no</c>
850
851  <c>Safari</c>
852  <c>no</c>
853  <c>no</c>
854  <c>no</c>
855  <c>yes</c>
856</texttable>
857<t>
858  (*) Does not implement the fallback behavior to "filename" described in
859  <xref target="disposition.parameter.filename"/>; a fix is planned for Firefox 5.
860</t>
861<t>
862  (**) Starting with Internet Explorer 9, but only implements UTF-8.
863</t>
864</section>
865-->
866</section>
867
868<section title="Advice on Generating Content-Disposition Header Fields" anchor="advice.generating">
869<t>
870  To successfully interoperate with existing and future user agents, senders of
871  the Content-Disposition header field are advised to:
872</t>
873<t>
874  <list style="symbols">
875    <t>Include a "filename" parameter when US-ASCII (<xref target="US-ASCII"/>) is sufficiently
876    expressive.</t>
877    <t>Use the 'token' form of the filename parameter only when it does not
878    contain disallowed characters (e.g., spaces); in such cases, the
879    quoted-string form should be used.</t>
880    <t>Avoid including the percent character followed by two hexadecimal
881    characters (e.g., %A9) in the filename parameter, since some existing
882    implementations consider it to be an escape character, while others will
883    pass it through unchanged.</t>
884    <t>Avoid including the "\" character in the quoted-string form of the
885    filename parameter, as escaping is not implemented by some user agents,
886    and "\" can be considered an illegal path character.</t>
887    <t>Avoid using non-ASCII characters in the filename parameter. Although
888    most existing implementations will decode them as ISO&nbhy;8859&nbhy;1, some
889    will apply heuristics to detect UTF-8, and thus might fail on certain names.</t>
890    <t>Include a "filename*" parameter where the desired filename cannot be
891    expressed faithfully using the "filename" form. Note that legacy user
892    agents will not process this, and will fall back to using the "filename"
893    parameter's content.
894    </t>
895    <t>When a "filename*" parameter is sent, to also generate a "filename"
896    parameter as a fallback for user agents that do not support the "filename*"
897    form, if possible. This can be done by substituting characters with
898    US-ASCII sequences (e.g., Unicode character point U+00E4 (LATIN SMALL
899    LETTER A WITH DIARESIS) by "ae"). Note that this may not be possible in
900    some locales.
901    </t>
902    <t>When a "filename" parameter is included as a fallback (as per above),
903    "filename" should occur first, due to parsing problems in some existing
904    implementations.<!--
905    <cref anchor="fallbackbug" source="jre">
906    Firefox is known to pick the wrong parameter; a bug fix is scheduled for
907    Firefox 5.</cref>
908    <cref anchor="NOTE-TO-RFC-EDITOR" source="jre">
909    PLEASE REMOVE THIS AND THE PRECEDING COMMENT BEFORE PUBLICATION AS RFC.</cref>-->
910    </t>
911    <t>Use UTF-8 as the encoding of the "filename*" parameter, when present,
912    because at least one existing implementation only implements that encoding.</t>
913  </list>
914</t>
915<t>
916  Note that this advice is based upon UA behavior at the time of writing, and
917  might be superseded. At the time of publication of this document,
918  <eref target="http://purl.org/NET/http/content-disposition-tests"/> provides
919  an overview of current levels of support in various implementations.
920</t>
921</section>
922
923<!--<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
924<t>
925  Note: the issues names in the change log entries for draft-reschke-rfc2183-in-http
926  refer to <eref target="http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-issues.html"/>.
927</t>
928
929<section title="Since draft-reschke-rfc2183-in-http-00">
930<t> 
931  Adjust terminology ("header" -&gt; "header field").
932  Update rfc2231-in-http reference.
933</t>
934</section>
935
936<section title="Since draft-reschke-rfc2183-in-http-01">
937<t> 
938  Update rfc2231-in-http reference. Actually define the "filename"
939  parameter. Add internationalization considerations.
940  Add examples using the RFC 5987 encoding.
941  Add overview over other approaches, plus a table reporting
942  implementation status.
943  Add and resolve issue "nodep2183".
944  Add issues "asciivsiso",
945  "deplboth", "quoted", and "registry".
946</t>
947</section>
948
949<section title="Since draft-reschke-rfc2183-in-http-02">
950<t>
951  Add and close issue "docfallback".
952  Close issues "asciivsiso", "deplboth", "quoted", and
953  "registry".
954</t>
955</section>
956
957<section title="Since draft-reschke-rfc2183-in-http-03">
958<t>
959  Updated to be a Working Draft of the IETF HTTPbis Working Group.
960</t>
961</section>
962
963<section title="Since draft-ietf-httpbis-content-disp-00" anchor="changes.since.00">
964<t>
965  Closed issues:
966  <list style="symbols">
967    <t>
968      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/242"/>:
969      "handling of unknown disposition types"
970    </t>
971  </list>
972</t>
973<t>
974  Slightly updated the notes about the proposed fallback behavior.
975</t>
976</section>
977
978<section title="Since draft-ietf-httpbis-content-disp-01" anchor="changes.since.01">
979<t>
980  Various editorial improvements.
981</t>
982</section>
983
984<section title="Since draft-ietf-httpbis-content-disp-02" anchor="changes.since.02">
985<t>
986  Closed issues:
987  <list style="symbols">
988    <t>
989      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/244"/>:
990      "state that repeating parameters are invalid"
991    </t>
992    <t>
993      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/245"/>:
994      "warn about %xx in filenames being misinterpreted"
995    </t>
996    <t>
997      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/246"/>:
998      "mention control chars when talking about postprecessing the filename parameter"
999    </t>
1000  </list>
1001</t>
1002<t>
1003  Update <xref target="alternatives.implementations"/>; Opera 10.63 RC
1004  implements the recommended fallback behavior.
1005</t>
1006</section>
1007
1008<section title="Since draft-ietf-httpbis-content-disp-03" anchor="changes.since.03">
1009<t>
1010  Closed issues:
1011  <list style="symbols">
1012    <t>
1013      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/252"/>:
1014      "'modification-date' *is* implemented in Konq 4.5"
1015    </t>
1016    <t>
1017      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/253"/>:
1018      "clarify what LWS means for the Content-Disp grammar"
1019    </t>
1020    <t>
1021      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/258"/>:
1022      "Avoid passive voice in message requirements"
1023    </t>
1024    <t>
1025      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/263"/>:
1026      "text about historical percent-decoding unclear"
1027    </t>
1028    <t>
1029      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/264"/>:
1030      "add explanation of language tagging"
1031    </t>
1032    <t>
1033      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/265"/>:
1034      "Clarify that C-D spec does not apply to multipart upload"
1035    </t>
1036  </list>
1037</t>
1038</section>
1039
1040<section title="Since draft-ietf-httpbis-content-disp-04" anchor="changes.since.04">
1041<t>
1042  Updated implementation information (Chrome 9 implements RFC 5987, IE 9 RC implements
1043  it for UTF-8 only).
1044</t>
1045<t>
1046  Clarify who requirements are on, add a section discussing conformance
1047  and handling of invalid field values in general.
1048</t>
1049<t>
1050  Closed issues:
1051  <list style="symbols">
1052     <t>
1053      <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/243"/>:
1054      "avoid stating ISO-8859-1 default for header param" (the default
1055      is still mentioned, but it was clarified what it applies to).
1056    </t>
1057   <t>
1058      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/272"/>:
1059      "Path Separator Characters"
1060    </t>
1061  </list>
1062</t>
1063</section>
1064
1065<section title="Since draft-ietf-httpbis-content-disp-05" anchor="changes.since.05">
1066<t>
1067  Editorial changes:
1068  Fixed two typos where the new Conformance section said "Content-Location" instead
1069  of "Content-Disposition". Cleaned up terminology ("user agent", "recipient",
1070  "sender", "message body", ...). Stated what the escape character for quoted-string
1071  is. Explained a use case for "inline" disposition type. Updated implementation
1072  notes with respect to the fallback behavior.
1073</t>
1074<t>
1075  Added appendix "Advice on Generating Content-Disposition Header Fields".
1076</t>
1077</section>
1078
1079<section title="Since draft-ietf-httpbis-content-disp-06" anchor="changes.since.06">
1080<t>
1081  Closed issues:
1082  <list style="symbols">
1083     <t>
1084      <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/278"/>:
1085      "conformance language"
1086    </t>
1087  </list>
1088</t>
1089</section>
1090
1091<section title="Since draft-ietf-httpbis-content-disp-07" anchor="changes.since.07">
1092<t>
1093  Rephrase the requirement about well-known file system locations, and also
1094  clarify that by "last path segment" we mean the actual filename.
1095  Added a forward reference from "invalid" to the section that defines a valid
1096  header field.
1097</t>
1098</section>
1099
1100<section title="Since draft-ietf-httpbis-content-disp-08" anchor="changes.since.08">
1101<t>
1102  Update: Internet Explorer 9 is released.
1103  Various editorial improvements.
1104  Add US-ASCII reference.
1105  Strengthen file extension handling requirement to MUST for those recipients
1106  that actually use file extensions to map media types.
1107</t>
1108</section>
1109
1110<section title="Since draft-ietf-httpbis-content-disp-09" anchor="changes.since.09">
1111<t>
1112  Editorial changes made during RFC-Editor AUTH48 phase.
1113</t>
1114</section>
1115
1116</section>
1117
1118-->
1119  </back>
1120
1121</rfc>
Note: See TracBrowser for help on using the repository browser.