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