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

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

apply RFC-Editor AUTH48 changes

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