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

Last change on this file was 1500, checked in by julian.reschke@…, 8 years ago

fix mime types

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