draft-ietf-httpbis-content-disp-06.txt   draft-ietf-httpbis-content-disp-07.txt 
HTTPbis Working Group J. Reschke HTTPbis Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Updates: 2616 (if approved) February 26, 2011 Updates: 2616 (if approved) March 14, 2011
Intended status: Standards Track Intended status: Standards Track
Expires: August 30, 2011 Expires: September 15, 2011
Use of the Content-Disposition Header Field in the Use of the Content-Disposition Header Field in the
Hypertext Transfer Protocol (HTTP) Hypertext Transfer Protocol (HTTP)
draft-ietf-httpbis-content-disp-06 draft-ietf-httpbis-content-disp-07
Abstract Abstract
RFC 2616 defines the Content-Disposition response header field, but RFC 2616 defines the Content-Disposition response header field, but
points out that it is not part of the HTTP/1.1 Standard. This points out that it is not part of the HTTP/1.1 Standard. This
specification takes over the definition and registration of Content- specification takes over the definition and registration of Content-
Disposition, as used in HTTP, and clarifies internationalization Disposition, as used in HTTP, and clarifies internationalization
aspects. aspects.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Disposition in the HTTP/1.1 specification, as currently revised by Disposition in the HTTP/1.1 specification, as currently revised by
the IETF HTTPbis working group. See also the IETF HTTPbis working group. See also
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/123>. <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/123>.
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://trac.tools.ietf.org/wg/httpbis/trac/ at <http://trac.tools.ietf.org/wg/httpbis/trac/
query?component=content-disp> and related documents (including fancy query?component=content-disp> and related documents (including fancy
diffs) can be found at <http://tools.ietf.org/wg/httpbis/>. diffs) can be found at <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix E.10. The changes in this draft are summarized in Appendix E.11.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 30, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 48 skipping to change at page 3, line 48
E.1. Since draft-reschke-rfc2183-in-http-00 . . . . . . . . . . 14 E.1. Since draft-reschke-rfc2183-in-http-00 . . . . . . . . . . 14
E.2. Since draft-reschke-rfc2183-in-http-01 . . . . . . . . . . 14 E.2. Since draft-reschke-rfc2183-in-http-01 . . . . . . . . . . 14
E.3. Since draft-reschke-rfc2183-in-http-02 . . . . . . . . . . 14 E.3. Since draft-reschke-rfc2183-in-http-02 . . . . . . . . . . 14
E.4. Since draft-reschke-rfc2183-in-http-03 . . . . . . . . . . 15 E.4. Since draft-reschke-rfc2183-in-http-03 . . . . . . . . . . 15
E.5. Since draft-ietf-httpbis-content-disp-00 . . . . . . . . . 15 E.5. Since draft-ietf-httpbis-content-disp-00 . . . . . . . . . 15
E.6. Since draft-ietf-httpbis-content-disp-01 . . . . . . . . . 15 E.6. Since draft-ietf-httpbis-content-disp-01 . . . . . . . . . 15
E.7. Since draft-ietf-httpbis-content-disp-02 . . . . . . . . . 15 E.7. Since draft-ietf-httpbis-content-disp-02 . . . . . . . . . 15
E.8. Since draft-ietf-httpbis-content-disp-03 . . . . . . . . . 15 E.8. Since draft-ietf-httpbis-content-disp-03 . . . . . . . . . 15
E.9. Since draft-ietf-httpbis-content-disp-04 . . . . . . . . . 16 E.9. Since draft-ietf-httpbis-content-disp-04 . . . . . . . . . 16
E.10. Since draft-ietf-httpbis-content-disp-05 . . . . . . . . . 16 E.10. Since draft-ietf-httpbis-content-disp-05 . . . . . . . . . 16
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 E.11. Since draft-ietf-httpbis-content-disp-06 . . . . . . . . . 16
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
RFC 2616 defines the Content-Disposition response header field in RFC 2616 defines the Content-Disposition response header field in
Section 19.5.1 of [RFC2616], but points out that it is not part of Section 19.5.1 of [RFC2616], but points out that it is not part of
the HTTP/1.1 Standard (Section 15.5): the HTTP/1.1 Standard (Section 15.5):
Content-Disposition is not part of the HTTP standard, but since it Content-Disposition is not part of the HTTP standard, but since it
is widely implemented, we are documenting its use and risks for is widely implemented, we are documenting its use and risks for
implementers. implementers.
skipping to change at page 7, line 15 skipping to change at page 7, line 15
o When the value contains path separator characters ("\" or "/"), o When the value contains path separator characters ("\" or "/"),
recipients SHOULD ignore all but the last path segment. This recipients SHOULD ignore all but the last path segment. This
prevents unintentional overwriting of well-known file system prevents unintentional overwriting of well-known file system
locations (such as "/etc/passwd"). locations (such as "/etc/passwd").
o Many platforms do not use Internet Media Types ([RFC2046]) to hold o Many platforms do not use Internet Media Types ([RFC2046]) to hold
type information in the file system, but rely on filename type information in the file system, but rely on filename
extensions instead. Trusting the server-provided file extension extensions instead. Trusting the server-provided file extension
could introduce a privilege escalation when the saved file is could introduce a privilege escalation when the saved file is
later opened (consider ".exe"). Thus, recipients need to ensure later opened (consider ".exe"). Thus, recipients SHOULD ensure
that a file extension is used that is safe, optimally matching the that a file extension is used that is safe, optimally matching the
media type of the received payload. media type of the received payload.
o Recipients are advised to strip or replace character sequences o Recipients SHOULD strip or replace character sequences that are
that are known to cause confusion both in user interfaces and in known to cause confusion both in user interfaces and in filenames,
filenames, such as control characters and leading and trailing such as control characters and leading and trailing whitespace.
whitespace.
o Other aspects recipients need to be aware of are names that have a o Other aspects recipients need to be aware of are names that have a
special meaning in the file system or in shell commands, such as special meaning in the file system or in shell commands, such as
"." and "..", "~", "|", and also device names. "." and "..", "~", "|", and also device names. Recipients SHOULD
ignore or substitute names like these.
Note: Many user agents do not properly handle the escape character Note: Many user agents do not properly handle the escape character
"\" when using the quoted-string form. Furthermore, some user "\" when using the quoted-string form. Furthermore, some user
agents erroneously try to perform unescaping of "percent" escapes agents erroneously try to perform unescaping of "percent" escapes
(see Appendix C.2), and thus might misinterpret filenames (see Appendix C.2), and thus might misinterpret filenames
containing the percent character followed by two hex digits. containing the percent character followed by two hex digits.
4.4. Disposition Parameter: Extensions 4.4. Disposition Parameter: Extensions
To enable future extensions, recipients SHOULD ignore unrecognized To enable future extensions, recipients SHOULD ignore unrecognized
skipping to change at page 12, line 37 skipping to change at page 12, line 37
Some user agents inspect the value (which defaults to ISO-8859-1 for Some user agents inspect the value (which defaults to ISO-8859-1 for
the quoted-string form) and switch to UTF-8 when it seems to be more the quoted-string form) and switch to UTF-8 when it seems to be more
likely to be the correct interpretation. likely to be the correct interpretation.
As with the approaches above, this is not interoperable and As with the approaches above, this is not interoperable and
furthermore risks misinterpreting the actual value. furthermore risks misinterpreting the actual value.
C.4. Implementations (to be removed by RFC Editor before publication) C.4. Implementations (to be removed by RFC Editor before publication)
Unfortunately, as of February 2011, neither the encoding defined in Unfortunately, as of March 2011, neither the encoding defined in RFCs
RFCs 2231 and 5987, nor any of the alternate approaches discussed 2231 and 5987, nor any of the alternate approaches discussed above
above was implemented interoperably. Thus, this specification was implemented interoperably. Thus, this specification recommends
recommends the approach defined in RFC 5987, which at least has the the approach defined in RFC 5987, which at least has the advantage of
advantage of actually being specified properly. actually being specified properly.
The table below shows the implementation support for the various The table below shows the implementation support for the various
approaches: approaches:
+---------------+------------+--------+--------------+--------------+ +---------------+------------+--------+--------------+--------------+
| User Agent | RFC | RFC | Percent | Encoding | | User Agent | RFC | RFC | Percent | Encoding |
| | 2231/5987 | 2047 | Encoding | Sniffing | | | 2231/5987 | 2047 | Encoding | Sniffing |
+---------------+------------+--------+--------------+--------------+ +---------------+------------+--------+--------------+--------------+
| Chrome | yes | yes | yes | yes | | Chrome | yes | yes | yes | yes |
| Firefox | yes (*) | yes | no | yes | | Firefox | yes (*) | yes | no | yes |
skipping to change at page 16, line 43 skipping to change at page 16, line 43
Editorial changes: Fixed two typos where the new Conformance section Editorial changes: Fixed two typos where the new Conformance section
said "Content-Location" instead of "Content-Disposition". Cleaned up said "Content-Location" instead of "Content-Disposition". Cleaned up
terminology ("user agent", "recipient", "sender", "message body", terminology ("user agent", "recipient", "sender", "message body",
...). Stated what the escape character for quoted-string is. ...). Stated what the escape character for quoted-string is.
Explained a use case for "inline" disposition type. Updated Explained a use case for "inline" disposition type. Updated
implementation notes with respect to the fallback behavior. implementation notes with respect to the fallback behavior.
Added appendix "Advice on Generating Content-Disposition Header Added appendix "Advice on Generating Content-Disposition Header
Fields". Fields".
E.11. Since draft-ietf-httpbis-content-disp-06
Closed issues:
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/278>:
"conformance language"
Index Index
C C
Content-Disposition header field 5 Content-Disposition header field 5
H H
Header Fields Header Fields
Content-Disposition 5 Content-Disposition 5
Author's Address Author's Address
 End of changes. 11 change blocks. 
17 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/