source: draft-ietf-httpbis-content-disp/03/draft-ietf-httpbis-content-disp.xml @ 1751

Last change on this file since 1751 was 1500, checked in by julian.reschke@…, 9 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: 31.6 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]>
26
27<rfc xmlns:x="http://purl.org/net/xml2rfc/ext" xmlns:ed="http://greenbytes.de/2002/rfcedit" ipr="trust200902" docName="draft-ietf-httpbis-content-disp-03" category="std" x:maturity-level="proposed" xml:lang="en" updates="2616">
28        <front>
29  <title abbrev="Content-Disposition in HTTP">Use of the Content-Disposition&#160;Header&#160;Field
30  in the Hypertext&#160;Transfer&#160;Protocol&#160;(HTTP)</title>
31  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
32    <organization abbrev="greenbytes">greenbytes GmbH</organization>
33    <address>
34      <postal>
35        <street>Hafenweg 16</street>
36        <city>Muenster</city><region>NW</region><code>48155</code>
37        <country>Germany</country>
38      </postal>
39      <email>julian.reschke@greenbytes.de</email>       
40      <uri>http://greenbytes.de/tech/webdav/</uri>     
41    </address>
42  </author>
43
44  <date month="October" year="2010" day="25"/>
45  <workgroup>HTTPbis Working Group</workgroup>
46 
47  <abstract>
48    <t>
49      HTTP/1.1 defines the Content-Disposition response header field,
50      but points out that it is not part of the HTTP/1.1 Standard.
51      This specification takes over the definition and registration of
52      Content-Disposition, as used in HTTP, and clarifies internationalization
53      aspects.
54    </t>
55  </abstract>
56 
57  <note title="Editorial Note (To be removed by RFC Editor before publication)">
58    <t>
59      This specification is expected to replace the definition of Content-Disposition
60      in the HTTP/1.1 specification, as currently revised by the IETF HTTPbis
61      working group. See also <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/123"/>.
62    </t>
63    <t>
64      Discussion of this draft should take place on the HTTPBIS working group
65      mailing list (ietf-http-wg@w3.org). The current issues list is
66      at <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/query?component=content-disp"/>
67      and related documents (including fancy diffs) can be found at
68      <eref target="http://tools.ietf.org/wg/httpbis/"/>.
69    </t>
70    <t>
71      The changes in this draft are summarized in <xref target="changes.since.02"/>.
72    </t>
73  </note>
74  </front>
75
76  <middle>
77
78<section title="Introduction" anchor="introduction">
79<t>
80  HTTP/1.1 defines the Content-Disposition response header field in <xref target="RFC2616" x:fmt="of" x:sec="19.5.1"/>,
81  but points out that it is not part of the HTTP/1.1 Standard (<xref target="RFC2616" x:fmt="sec" x:sec="15.5"/>):
82</t>
83<x:blockquote cite="http://tools.ietf.org/html/rfc2616#section-15.5">
84  <t>
85    Content-Disposition is not part of the HTTP standard, but since it is
86    widely implemented, we are documenting its use and risks for implementers.
87  </t>
88</x:blockquote>
89<t>
90  This specification takes over the definition and registration of
91  Content-Disposition, as used in HTTP.
92  Based on interoperability testing with existing User Agents,
93  it fully defines a profile of the
94  features defined in the Multipurpose Internet Mail Extensions (MIME) variant (<xref target="RFC2183"/>) of the
95  header field, and also clarifies internationalization
96  aspects.
97</t>
98</section> 
99
100<section title="Notational Conventions">
101<t>
102  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
103  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
104  are to be interpreted as described in <xref target="RFC2119"/>.
105</t>
106<t>
107  This specification uses the augmented BNF notation defined in
108  <xref target="RFC2616" x:fmt="of" x:sec="2.1"/>, including its rules for
109  linear whitespace (LWS).
110</t>
111</section> 
112
113<section title="Header Field Definition" anchor="header.field.definition">
114  <iref item="Headers" subitem="Content-Disposition" primary="true" x:for-anchor=""/>
115  <iref item="Content-Disposition header" primary="true" x:for-anchor=""/>
116<t>
117  The Content-Disposition response header field is used to convey additional
118  information about how to process the response payload, and also can be used
119  to attach additional metadata, such as the filename to use when saving the
120  response payload locally.
121</t>
122
123<section title="Grammar">
124<figure><artwork type="abnf2616">
125  content-disposition = "Content-Disposition" ":"
126                         disposition-type *( ";" disposition-parm )
127
128  disposition-type    = "inline" | "attachment" | disp-ext-type
129                      ; case-insensitive
130  disp-ext-type       = token
131
132  disposition-parm    = filename-parm | disp-ext-parm
133
134  filename-parm       = "filename" "=" value
135                      | "filename*" "=" ext-value
136 
137  disp-ext-parm       = token "=" value
138                      | ext-token "=" ext-value
139  ext-token           = &lt;the characters in token, followed by "*"&gt;
140</artwork></figure>
141
142<figure>
143<preamble>Defined in <xref target="RFC2616"/>:</preamble>
144<artwork type="abnf2616">
145  token       = &lt;token, defined in <xref target="RFC2616" x:fmt="," x:sec="2.2"/>&gt;
146  value       = &lt;value, defined in <xref target="RFC2616" x:fmt="," x:sec="3.6"/>&gt;
147</artwork></figure>
148<figure>
149<preamble>Defined in <xref target="RFC5987"/>:</preamble>
150<artwork type="abnf2616">
151  ext-value   = &lt;ext-value, defined in <xref target="RFC5987" x:sec="3.2"/>&gt;
152</artwork></figure>
153
154<t>
155  Parameter names &MUST-NOT; be repeated; a header field value with
156  multiple instances of the same parameter &SHOULD; be treated as invalid.
157</t>
158
159</section>
160
161<section title="Disposition Type" anchor="disposition.type">
162<t>
163  If the disposition type matches "attachment" (case-insensitively), this
164  indicates that the user agent should prompt the user to save the response
165  locally, rather than process it normally (as per its media type).
166</t>
167<t>
168  On the other hand, if it matches "inline" (case-insensitively), this implies
169  default processing.
170</t>
171<t>
172  Unknown or unhandled disposition types &SHOULD; be handled the same way as
173  "attachment" (see also <xref target="RFC2183" x:fmt="," x:sec="2.8"/>).
174</t>
175</section>
176
177<section title="Disposition Parameter: 'Filename'" anchor="disposition.parameter.filename">
178<t>
179  The parameters "filename" and "filename*", to be matched case-insensitively,
180  provide information on how to construct a filename for storing the message
181  payload.
182</t>
183<t>
184  Depending on the disposition type, this information might be used right away
185  (in the "save as..." interaction caused for the "attachment" disposition type),
186  or later on (for instance, when the user decides to save the contents of the
187  current page being displayed).
188</t>
189<t>
190  The parameters "filename" and "filename*" differ only in that "filename*" uses
191  the encoding defined in <xref target="RFC5987"/>, allowing the use
192  of characters not present in the ISO-8859-1 character set (<xref target="ISO-8859-1"/>).
193</t>
194<t>
195  Many user agent implementations predating this specification
196  do not understand the "filename*" parameter. Therefore, when both "filename"
197  and "filename*" are present in a single header field value, recipients
198  &SHOULD; pick "filename*" and ignore "filename". This way, senders
199  can avoid special-casing specific user agents by sending both the
200  more expressive "filename*" parameter, and the "filename" parameter
201  as fallback for legacy recipients (see <xref target="examples"/> for
202  an example).
203</t>
204<t>
205  It is essential that user agents treat the specified filename as advisory
206  only, thus be very careful in extracting the desired information.
207  In particular:
208  <list style="symbols">
209    <x:lt><t>
210      When the value contains path separator characters, all but the last
211      segment &SHOULD; be ignored. This prevents unintentional overwriting
212      of well-known file system location (such as "/etc/passwd").
213    </t></x:lt>
214    <x:lt><t>
215      Many platforms do not use Internet Media Types (<xref target="RFC2046"/>)
216      to hold type information in the file system, but rely on filename
217      extensions instead. Trusting the server-provided file extension could
218      introduce a privilege escalation when the saved file is later opened
219      (consider ".exe"). Thus, recipients need to ensure that a file extension
220      is used that is safe, optimally matching the media type of the received
221      payload.
222    </t></x:lt>
223    <x:lt><t>
224      Recipients are advised to strip or replace character sequences that are
225      known to cause confusion both in user interfaces and in filenames, such as
226      control characters and leading and trailing whitespace.
227    </t></x:lt>
228    <x:lt><t>
229      Other aspects recipients need to be aware of are names that have a
230      special meaning in the file system or in shell commands, such as "." and "..",
231      "~", "|", and also device names.
232    </t></x:lt>
233  </list>
234</t>
235<x:note>
236  <t>
237    <x:h>Note:</x:h> Many user agents do not properly handle escape characters
238    when using the quoted-string form. Furthermore, some user agents
239    erroneously try to perform unescaping of "percent" escapes (see
240    <xref target="alternatives.percent"/>), and thus might misinterpret
241    filenames containing the percent character followed by two hex digits.
242  </t>
243</x:note>
244</section>
245
246<section title="Disposition Parameter: Extensions" anchor="disposition.parameter.extensions">
247<t>
248  To enable future extensions, unknown parameters &SHOULD; be ignored (see also <xref target="RFC2183" x:fmt="," x:sec="2.8"/>).
249</t>
250</section>
251
252<section title="Extensibility" anchor="extensibility">
253<t>
254  Note that <xref target="RFC2183" x:fmt="of" x:sec="9"/> defines IANA registries both
255  for disposition types and disposition parameters. This registry is
256  shared by different protocols using Content-Disposition, such as MIME and HTTP.
257  Therefore, not all registered values may make sense in the context of HTTP.
258</t>
259</section>
260
261</section> 
262
263<section title="Examples" anchor="examples">
264
265<figure>
266<preamble>
267Direct UA to show "save as" dialog, with a filename of "example.html": 
268</preamble>
269<artwork type="example">
270Content-Disposition: Attachment; filename=example.html
271</artwork></figure>
272<figure>
273<preamble>
274Direct UA to behave as if the Content-Disposition header field wasn't present,
275but to remember the filename "example.html" for a subsequent save operation:
276</preamble>
277<artwork type="example" x:indent-with="  ">
278Content-Disposition: INLINE; FILENAME= "example.html"
279</artwork></figure>
280<figure>
281<preamble>
282Direct UA to show "save as" dialog, with a filename of "an example":
283</preamble>
284<artwork type="example">
285Content-Disposition: Attachment; Filename*=UTF-8'<x:highlight>en</x:highlight>'an<x:highlight>%20</x:highlight>example
286</artwork>
287<postamble>Note that this example uses the extended encoding defined in
288<xref target="RFC5987"/> to specify that the natural language of the filename
289is English, and also to encode the space character which is not allowed in the
290token production.
291</postamble>
292</figure>
293<figure>
294<preamble>
295Direct UA to show "save as" dialog, with a filename containing the Unicode character  U+20AC (EURO SIGN):
296</preamble>
297<artwork type="example" x:indent-with="  ">
298Content-Disposition: attachment;
299                     filename*= UTF-8''<x:highlight>%e2%82%ac</x:highlight>%20rates
300</artwork>
301<postamble>
302  Here, the encoding defined in <xref target="RFC5987"/> is also used to encode the
303  non-ISO-8859-1 character.
304</postamble>
305</figure>
306<figure>
307<preamble>
308Same as above, but adding the "filename" parameter for compatibility with
309user agents not implementing RFC 5987:
310</preamble>
311<artwork type="example" x:indent-with="  ">
312Content-Disposition: attachment;
313                     filename="EURO rates";
314                     filename*=utf-8''<x:highlight>%e2%82%ac</x:highlight>%20rates
315</artwork>
316<postamble>
317  Note: as of October 2010, those user agents that do not support the RFC 5987
318  encoding ignore "filename*" when it occurs after "filename". Unfortunately,
319  some user agents that do support RFC 5987 do pick the "filename" rather
320  than the "filename*" parameter when it occurs first; it is expected that
321  this situation is going to improve soon.
322</postamble>
323</figure>
324
325</section>
326
327<section title="Internationalization Considerations" anchor="i18n">
328<t>
329  The "filename*" parameter (<xref target="disposition.parameter.filename"/>),
330  using the encoding defined in <xref target="RFC5987"/>, allows the
331  server to transmit characters outside the ISO-8859-1 character set,
332  and also to optionally specify the language in use.
333</t>
334<t>
335  Future parameters might also require internationalization, in which case
336  the same encoding can be used.
337</t>
338</section>
339
340<section title="Security Considerations" anchor="security.considerations">
341<t>
342  Using server-supplied information for constructing local filenames introduces
343  many risks. These are summarized in <xref target="disposition.parameter.filename"/>.
344</t>
345<t>
346  Furthermore, implementers also ought to be aware of the Security
347  Considerations applying to HTTP (see <xref target="RFC2616" x:fmt="of" x:sec="15"/>), and also the parameter encoding defined in <xref target="RFC5987"/>
348  (see <xref target="RFC5987" x:fmt="sec" x:sec="5"/>).
349</t>
350</section> 
351
352<section title="IANA Considerations" anchor="iana.considerations">
353
354<section title="Registry for Disposition Values and Parameter" anchor="registry">
355<t>
356  This specification does not introduce any changes to the registration
357  procedures for disposition values and parameters that are defined in
358  <xref target="RFC2183" x:fmt="of" x:sec="9"/>.
359</t>
360</section>
361
362<section title="Header Field Registration" anchor="header.field.registration"> 
363<t>
364  This document updates the definition of the Content-Disposition HTTP header field
365  in the permanent HTTP header field registry (see <xref target="RFC3864"/>).
366</t>
367<t>
368<list style="hanging">
369  <t hangText="Header field name:">Content-Disposition</t>
370  <t hangText="Applicable protocol:">http</t>
371  <t hangText="Status:">standard</t>
372  <t hangText="Author/Change controller:">IETF</t>
373  <t hangText="Specification document:">this specification (<xref target="header.field.definition"/>)</t>
374</list>
375</t>
376</section>
377
378</section> 
379
380<section title="Acknowledgements">
381<t>
382  Thanks to Adam Barth, Rolf Eike Beer, Bjoern Hoehrmann, Alfred Hoenes, Roar Lauritzsen,
383  Henrik Nordstrom, and Mark Nottingham for their valuable feedback.
384</t>
385</section> 
386
387  </middle>
388  <back>
389 
390<references title="Normative References">
391 
392  <reference anchor="RFC2119">
393    <front>
394      <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
395      <author initials="S." surname="Bradner" fullname="Scott Bradner">
396        <organization>Harvard University</organization>
397        <address><email>sob@harvard.edu</email></address>
398      </author>
399      <date month="March" year="1997"/>
400      <area>General</area>
401      <keyword>keyword</keyword>
402    </front>
403    <seriesInfo name="BCP" value="14"/>
404    <seriesInfo name="RFC" value="2119"/>
405  </reference>
406
407  <reference anchor="RFC2616">
408    <front>
409      <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
410      <author initials="R." surname="Fielding" fullname="R. Fielding">
411        <organization>University of California, Irvine</organization>
412        <address><email>fielding@ics.uci.edu</email></address>
413      </author>
414      <author initials="J." surname="Gettys" fullname="J. Gettys">
415        <organization>W3C</organization>
416        <address><email>jg@w3.org</email></address>
417      </author>
418      <author initials="J." surname="Mogul" fullname="J. Mogul">
419        <organization>Compaq Computer Corporation</organization>
420        <address><email>mogul@wrl.dec.com</email></address>
421      </author>
422      <author initials="H." surname="Frystyk" fullname="H. Frystyk">
423        <organization>MIT Laboratory for Computer Science</organization>
424        <address><email>frystyk@w3.org</email></address>
425      </author>
426      <author initials="L." surname="Masinter" fullname="L. Masinter">
427        <organization>Xerox Corporation</organization>
428        <address><email>masinter@parc.xerox.com</email></address>
429      </author>
430      <author initials="P." surname="Leach" fullname="P. Leach">
431        <organization>Microsoft Corporation</organization>
432        <address><email>paulle@microsoft.com</email></address>
433      </author>
434      <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
435        <organization>W3C</organization>
436        <address><email>timbl@w3.org</email></address>
437      </author>
438      <date month="June" year="1999"/>
439    </front>
440    <seriesInfo name="RFC" value="2616"/>
441  </reference>
442
443  <reference anchor="RFC5987">
444        <front>
445      <title>Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters</title>
446      <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke">
447        <organization abbrev="greenbytes">greenbytes GmbH</organization>
448        <address>
449          <postal>
450            <street>Hafenweg 16</street>
451            <city>Muenster</city><region>NW</region><code>48155</code>
452            <country>Germany</country>
453          </postal>
454          <email>julian.reschke@greenbytes.de</email>   
455          <uri>http://greenbytes.de/tech/webdav/</uri> 
456        </address>
457      </author>
458      <date month="August" year="2010"/>
459    </front>
460    <seriesInfo name="RFC" value="5987"/>
461  </reference>
462
463  <reference anchor="ISO-8859-1">
464    <front>
465      <title>Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1</title>
466      <author>
467        <organization>International Organization for Standardization</organization>
468      </author>
469      <date year="1998"/>
470    </front>
471    <seriesInfo name="ISO/IEC" value="8859-1:1998"/>
472  </reference>
473
474</references>
475 
476<references title="Informative References">
477
478  <reference anchor="RFC2046">
479    <front>
480      <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
481      <author initials="N." surname="Freed" fullname="Ned Freed">
482        <organization>Innosoft International, Inc.</organization>
483        <address><email>ned@innosoft.com</email></address>
484      </author>
485      <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
486        <organization>First Virtual Holdings</organization>
487        <address><email>nsb@nsb.fv.com</email></address>
488      </author>
489      <date month="November" year="1996"/>
490    </front>
491    <seriesInfo name="RFC" value="2046"/>
492  </reference>
493
494  <reference anchor="RFC2047">
495    <front>
496      <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
497      <author initials="K." surname="Moore" fullname="Keith Moore">
498        <organization>University of Tennessee</organization>
499        <address><email>moore@cs.utk.edu</email></address>
500      </author>
501      <date month="November" year="1996"/>
502    </front>
503    <seriesInfo name="RFC" value="2047"/>
504  </reference>
505
506  <reference anchor="RFC2183">
507    <front>
508      <title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</title>
509      <author initials="R." surname="Troost" fullname="Rens Troost">
510        <organization>New Century Systems</organization>
511        <address><email>rens@century.com</email></address>
512      </author>
513      <author initials="S." surname="Dorner" fullname="Steve Dorner">
514        <organization>QUALCOMM Incorporated</organization>
515        <address><email>sdorner@qualcomm.com</email></address>
516      </author>
517      <author initials="K." surname="Moore" fullname="Keith Moore">
518        <organization>Department of Computer Science</organization>
519        <address><email>moore@cs.utk.edu</email></address>
520      </author>
521      <date year="1997" month="August"/>
522    </front>
523    <seriesInfo name="RFC" value="2183"/>
524  </reference>
525
526  <reference anchor="RFC2231">
527    <front>
528      <title abbrev="MIME Value and Encoded Word Extensions">MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations</title>
529      <author initials="N." surname="Freed" fullname="Ned Freed">
530        <organization abbrev="Innosoft">Innosoft International, Inc.</organization>
531        <address><email>ned.freed@innosoft.com</email></address>
532      </author>
533      <author initials="K." surname="Moore" fullname="Keith Moore">
534        <organization>University of Tennessee</organization>
535        <address><email>moore@cs.utk.edu</email></address>
536      </author>
537      <date year="1997" month="November"/>
538    </front>
539    <seriesInfo name="RFC" value="2231"/>
540  </reference>
541
542  <reference anchor="RFC3629">
543    <front>
544      <title>UTF-8, a transformation format of ISO 10646</title>
545      <author initials="F." surname="Yergeau" fullname="F. Yergeau">
546        <organization>Alis Technologies</organization>
547        <address><email>fyergeau@alis.com</email></address>
548      </author>
549      <date month="November" year="2003"/>
550    </front>
551    <seriesInfo name="STD" value="63"/>
552    <seriesInfo name="RFC" value="3629"/>
553  </reference>
554
555  <reference anchor="RFC3864">
556    <front>
557      <title>Registration Procedures for Message Header Fields</title>
558      <author initials="G." surname="Klyne" fullname="G. Klyne">
559        <organization>Nine by Nine</organization>
560        <address><email>GK-IETF@ninebynine.org</email></address>
561      </author>
562      <author initials="M." surname="Nottingham" fullname="M. Nottingham">
563        <organization>BEA Systems</organization>
564        <address><email>mnot@pobox.com</email></address>
565      </author>
566      <author initials="J." surname="Mogul" fullname="J. Mogul">
567        <organization>HP Labs</organization>
568        <address><email>JeffMogul@acm.org</email></address>
569      </author>
570      <date year="2004" month="September"/>
571    </front>
572    <seriesInfo name="BCP" value="90"/>
573    <seriesInfo name="RFC" value="3864"/>
574  </reference>
575
576  <reference anchor="RFC3986">
577   <front>
578    <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
579    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
580      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
581      <address>
582         <email>timbl@w3.org</email>
583         <uri>http://www.w3.org/People/Berners-Lee/</uri>
584      </address>
585    </author>
586    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
587      <organization abbrev="Day Software">Day Software</organization>
588      <address>
589        <email>fielding@gbiv.com</email>
590        <uri>http://roy.gbiv.com/</uri>
591      </address>
592    </author>
593    <author initials="L." surname="Masinter" fullname="Larry Masinter">
594      <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
595      <address>
596        <email>LMM@acm.org</email>
597        <uri>http://larry.masinter.net/</uri>
598      </address>
599    </author>
600    <date month="January" year="2005"/>
601   </front>
602   <seriesInfo name="STD" value="66"/>
603   <seriesInfo name="RFC" value="3986"/>
604  </reference>
605
606</references>
607
608<section title="Changes from the RFC 2616 Definition" anchor="changes.from.rfc2616">
609<t>
610  Compared to <xref target="RFC2616" x:fmt="of" x:sec="19.5.1"/>, the following
611  normative changes reflecting actual implementations have been made:
612<list style="symbols">
613  <t>
614    According to RFC 2616, the disposition type "attachment" only applies to
615    content of type "application/octet-stream". This restriction has been
616    removed, because user agents in practice do not check the content type, and
617    it also discourages properly declaring the media type.
618  </t>
619  <t>
620    RFC 2616 only allows "quoted-string" for the filename parameter. This
621    would be an exceptional parameter syntax, and also doesn't reflect actual
622    use.
623  </t>
624  <t>
625    The definition for the disposition type "inline" (<xref target="RFC2183" x:fmt="," x:sec="2.1"/>)
626    has been re-added with a suggestion for its processing.
627  </t>
628  <t>
629    This specification requires support for the extended parameter encoding
630    defined in <xref target="RFC5987"/>.
631  </t>
632</list>
633</t>
634</section>
635
636<section title="Differences compared to RFC 2183" anchor="diffs.compared.to.rfc2183">
637<t>
638  <xref target="RFC2183" x:fmt="of" x:sec="2"/> defines several additional
639  disposition parameters: "creation-date", "modification-date",
640  "quoted-date-time", and "size". These do not appear to be implemented by
641  any user agent, thus have been omitted from this specification.
642</t>
643</section>
644
645<section title="Alternative Approaches to Internationalization" anchor="alternatives">
646<t>
647  By default, HTTP header field parameters cannot carry characters outside
648  the ISO-8859-1 (<xref target="ISO-8859-1"/>) character encoding (see
649  <xref target="RFC2616" x:fmt="," x:sec="2.2"/>). For the "filename"
650  parameter, this of course is an unacceptable restriction.
651</t>
652<t>
653  Unfortunately, user agent implementers have not managed to come up with
654  an interoperable approach, although the IETF Standards Track specifies
655  exactly one solution (<xref target="RFC2231"/>, clarified and profiled for
656  HTTP in <xref target="RFC5987"/>).
657</t>
658<t>
659  For completeness, the sections below describe the various approaches that
660  have been tried, and explains how they are inferior to the RFC 5987
661  encoding used in this specification.
662</t>
663
664<section title="RFC 2047 Encoding" anchor="alternatives.rfc2047">
665<t>
666  RFC 2047 defines an encoding mechanism for
667  header fields, but this encoding is not supposed to be used for
668  header field parameters - see <xref target="RFC2047" x:fmt="of" x:sec="5"/>: 
669</t>
670<x:blockquote cite="http://tools.ietf.org/html/rfc2047#section-5">
671  <t>
672    An 'encoded-word' MUST NOT appear within a 'quoted-string'.
673  </t>
674  <t>
675    ...
676  </t>
677  <t>
678    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'.
679  </t>
680</x:blockquote>
681<t>
682  In practice, some user agents implement the encoding, some do not
683  (exposing the encoded string to the user), and some get confused by it.
684</t>
685</section>
686
687<section title="Percent Encoding" anchor="alternatives.percent">
688<t>
689  Some user agents accept percent encoded (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>)
690  sequences of characters encoded using the UTF-8 (<xref target="RFC3629"/>) character encoding.
691</t>
692<t>
693  In practice, this is hard to use because those user agents
694  that do not support it will display the escaped character sequence to the user.
695</t>
696<t>
697  Furthermore, the first user agent to implement this did choose the encoding
698  based on local settings; thus making it very hard to use in multi-lingual
699  environments.
700</t>
701</section>
702
703<section title="Encoding Sniffing" anchor="alternatives.sniff">
704<t>
705  Some user agents inspect the value (which defaults to ISO-8859-1) and
706  switch to UTF-8 when it seems to be more likely to be the correct
707  interpretation.
708</t>
709<t>
710  As with the approaches above, this is not interoperable and furthermore
711  risks misinterpreting the actual value.
712</t>
713</section>
714
715<section title="Implementations (to be removed by RFC Editor before publication)" anchor="alternatives.implementations">
716<t>
717  Unfortunately, as of October 2010, neither the encoding defined in RFCs 2231
718  and 5987, nor any of the alternate approaches discussed above was
719  implemented interoperably. Thus, this specification recommends the approach
720  defined in RFC 5987, which at least has the advantage of actually being
721  specified properly.
722</t>
723<t>
724  The table below shows the implementation support for the various approaches:
725</t>
726<texttable align="left">
727  <ttcol>User Agent</ttcol>
728  <ttcol>RFC 2231/5987</ttcol>
729  <ttcol>RFC 2047</ttcol>
730  <ttcol>Percent Encoding</ttcol>
731  <ttcol>Encoding Sniffing</ttcol>
732 
733  <c>Chrome</c>
734  <c>no</c>
735  <c>yes</c>
736  <c>yes</c>
737  <c>yes</c>
738
739  <c>Firefox</c>
740  <c>yes (*)</c>
741  <c>yes</c>
742  <c>no</c>
743  <c>yes</c>
744
745  <c>Internet Explorer</c>
746  <c>no</c>
747  <c>no</c>
748  <c>yes</c>
749  <c>no</c>
750
751  <c>Konqueror</c>
752  <c>yes</c>
753  <c>no</c>
754  <c>no</c>
755  <c>no</c>
756
757  <c>Opera</c>
758  <c>yes</c>
759  <c>no</c>
760  <c>no</c>
761  <c>no</c>
762
763  <c>Safari</c>
764  <c>no</c>
765  <c>no</c>
766  <c>no</c>
767  <c>yes</c>
768 
769  <postamble>
770  (*) Does not implement the fallback behavior to "filename" described in
771  <xref target="disposition.parameter.filename"/>.
772  </postamble>
773
774</texttable>
775
776</section>
777
778</section>
779
780
781<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
782<t>
783  Note: the issues names in the change log entries for draft-reschke-rfc2183-in-http
784  refer to <eref target="http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-issues.html"/>.
785</t>
786
787<section title="Since draft-reschke-rfc2183-in-http-00">
788<t> 
789  Adjust terminology ("header" -&gt; "header field").
790  Update rfc2231-in-http reference.
791</t>
792</section>
793
794<section title="Since draft-reschke-rfc2183-in-http-01">
795<t> 
796  Update rfc2231-in-http reference. Actually define the "filename"
797  parameter. Add internationalization considerations.
798  Add examples using the RFC 5987 encoding.
799  Add overview over other approaches, plus a table reporting
800  implementation status.
801  Add and resolve issue "nodep2183".
802  Add issues "asciivsiso",
803  "deplboth", "quoted", and "registry".
804</t>
805</section>
806
807<section title="Since draft-reschke-rfc2183-in-http-02">
808<t>
809  Add and close issue "docfallback".
810  Close issues "asciivsiso", "deplboth", "quoted", and
811  "registry".
812</t>
813</section>
814
815<section title="Since draft-reschke-rfc2183-in-http-03">
816<t>
817  Updated to be a Working Draft of the IETF HTTPbis Working Group.
818</t>
819</section>
820
821<section title="Since draft-ietf-httpbis-content-disp-00" anchor="changes.since.00">
822<t>
823  Closed issues:
824  <list style="symbols">
825    <t>
826      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/242"/>:
827      "handling of unknown disposition types"
828    </t>
829  </list>
830</t>
831<t>
832  Slightly updated the notes about the proposed fallback behavior.
833</t>
834</section>
835
836<section title="Since draft-ietf-httpbis-content-disp-01" anchor="changes.since.01">
837<t>
838  Various editorial improvements.
839</t>
840</section>
841
842<section title="Since draft-ietf-httpbis-content-disp-02" anchor="changes.since.02">
843<t>
844  Closed issues:
845  <list style="symbols">
846    <t>
847      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/244"/>:
848      "state that repeating parameters are invalid"
849    </t>
850    <t>
851      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/245"/>:
852      "warn about %xx in filenames being misinterpreted"
853    </t>
854    <t>
855      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/246"/>:
856      "mention control chars when talking about postprecessing the filename parameter"
857    </t>
858  </list>
859</t>
860<t>
861  Update <xref target="alternatives.implementations"/>; Opera 10.63 RC
862  implements the recommended fallback behavior.
863</t>
864</section>
865</section>
866
867
868  </back>
869
870</rfc>
Note: See TracBrowser for help on using the repository browser.