draft-ietf-httpbis-content-disp-07.txt   draft-ietf-httpbis-content-disp-08.txt 
HTTPbis Working Group J. Reschke HTTPbis Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Updates: 2616 (if approved) March 14, 2011 Updates: 2616 (if approved) March 14, 2011
Intended status: Standards Track Intended status: Standards Track
Expires: September 15, 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-07 draft-ietf-httpbis-content-disp-08
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.11. The changes in this draft are summarized in Appendix E.12.
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/.
skipping to change at page 3, line 49 skipping to change at page 3, line 49
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
E.11. Since draft-ietf-httpbis-content-disp-06 . . . . . . . . . 16 E.11. Since draft-ietf-httpbis-content-disp-06 . . . . . . . . . 16
E.12. Since draft-ietf-httpbis-content-disp-07 . . . . . . . . . 17
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 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
skipping to change at page 4, line 45 skipping to change at page 4, line 45
3. Conformance and Error Handling 3. Conformance and Error Handling
This specification defines conformance criteria for both senders This specification defines conformance criteria for both senders
(usually, HTTP origin servers) and recipients (usually, HTTP user (usually, HTTP origin servers) and recipients (usually, HTTP user
agents) of the Content-Disposition header field. An implementation agents) of the Content-Disposition header field. An implementation
is considered conformant if it complies with all of the requirements is considered conformant if it complies with all of the requirements
associated with its role. associated with its role.
This specification also defines certain forms of the header field- This specification also defines certain forms of the header field-
value to be invalid, using both ABNF and prose requirements, but it value to be invalid, using both ABNF and prose requirements
does not define special handling of these invalid field-values. (Section 4), but it does not define special handling of these invalid
field-values.
Senders MUST NOT generate Content-Disposition header fields that are Senders MUST NOT generate Content-Disposition header fields that are
invalid. invalid.
Recipients MAY take steps to recover a usable field-value from an Recipients MAY take steps to recover a usable field-value from an
invalid header field, but SHOULD NOT reject the message outright, invalid header field, but SHOULD NOT reject the message outright,
unless this is explicitly desirable behaviour (e.g., the unless this is explicitly desirable behaviour (e.g., the
implementation is a validator). As such, the default handling of implementation is a validator). As such, the default handling of
invalid fields is to ignore them. invalid fields is to ignore them.
skipping to change at page 7, line 6 skipping to change at page 7, line 6
value, recipients SHOULD pick "filename*" and ignore "filename". value, recipients SHOULD pick "filename*" and ignore "filename".
This way, senders can avoid special-casing specific user agents by This way, senders can avoid special-casing specific user agents by
sending both the more expressive "filename*" parameter, and the sending both the more expressive "filename*" parameter, and the
"filename" parameter as fallback for legacy recipients (see Section 5 "filename" parameter as fallback for legacy recipients (see Section 5
for an example). for an example).
It is essential that recipients treat the specified filename as It is essential that recipients treat the specified filename as
advisory only, thus be very careful in extracting the desired advisory only, thus be very careful in extracting the desired
information. In particular: information. In particular:
o When the value contains path separator characters ("\" or "/"), o Recipients MUST NOT be able to write into any location other than
recipients SHOULD ignore all but the last path segment. This one to which they are specifically entitled. To illustrate the
prevents unintentional overwriting of well-known file system problem consider the consequences of being able to overwrite well-
locations (such as "/etc/passwd"). known system locations (such as "/etc/passwd"). One strategy to
achieve this is to never trust folder name information in the
filename parameter, for instance by stripping all but the last
path segment and only consider the actual filename (where 'path
segment' are the components of the field value delimited by the
path separator characters "\" and "/").
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 SHOULD 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 SHOULD strip or replace character sequences that are o Recipients SHOULD strip or replace character sequences that are
skipping to change at page 9, line 40 skipping to change at page 9, line 40
Applicable protocol: http Applicable protocol: http
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: this specification (Section 4) Specification document: this specification (Section 4)
9. Acknowledgements 9. Acknowledgements
Thanks to Adam Barth, Rolf Eike Beer, Bjoern Hoehrmann, Alfred Thanks to Adam Barth, Rolf Eike Beer, Stewart Bryant, Bjoern
Hoenes, Roar Lauritzsen, Henrik Nordstrom, and Mark Nottingham for Hoehrmann, Alfred Hoenes, Roar Lauritzsen, Alexey Melnikov, Henrik
their valuable feedback. Nordstrom, and Mark Nottingham for their valuable feedback.
10. References 10. References
10.1. Normative References 10.1. Normative References
[ISO-8859-1] International Organization for Standardization, [ISO-8859-1] International Organization for Standardization,
"Information technology -- 8-bit single-byte coded "Information technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. graphic character sets -- Part 1: Latin alphabet No.
1", ISO/IEC 8859-1:1998, 1998. 1", ISO/IEC 8859-1:1998, 1998.
skipping to change at page 14, line 23 skipping to change at page 14, line 23
above), "filename" should occur first, due to parsing problems in above), "filename" should occur first, due to parsing problems in
some existing implementations. [[fallbackbug: Firefox is known to some existing implementations. [[fallbackbug: Firefox is known to
pick the wrong parameter; a bug fix is scheduled for Firefox 5. pick the wrong parameter; a bug fix is scheduled for Firefox 5.
--jre]] --jre]]
o Use UTF-8 as the encoding of the "filename*" parameter, when o Use UTF-8 as the encoding of the "filename*" parameter, when
present, because at least one existing implementation only present, because at least one existing implementation only
implements that encoding. implements that encoding.
Note that this advice is based upon UA behaviour at the time of Note that this advice is based upon UA behaviour at the time of
writing, and might be superseded. writing, and might be superseded. At the time of publication of this
<http://purl.org/NET/http/content-disposition-tests> provides an document, <http://purl.org/NET/http/content-disposition-tests>
overview of current levels of support in various implementations. provides an overview of current levels of support in various
implementations.
Appendix E. Change Log (to be removed by RFC Editor before publication) Appendix E. Change Log (to be removed by RFC Editor before publication)
Note: the issues names in the change log entries for Note: the issues names in the change log entries for
draft-reschke-rfc2183-in-http refer to <http://greenbytes.de/tech/ draft-reschke-rfc2183-in-http refer to <http://greenbytes.de/tech/
webdav/draft-reschke-rfc2183-in-http-issues.html>. webdav/draft-reschke-rfc2183-in-http-issues.html>.
E.1. Since draft-reschke-rfc2183-in-http-00 E.1. Since draft-reschke-rfc2183-in-http-00
Adjust terminology ("header" -> "header field"). Update rfc2231-in- Adjust terminology ("header" -> "header field"). Update rfc2231-in-
skipping to change at page 17, line 5 skipping to change at page 17, line 5
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 E.11. Since draft-ietf-httpbis-content-disp-06
Closed issues: Closed issues:
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/278>: o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/278>:
"conformance language" "conformance language"
E.12. Since draft-ietf-httpbis-content-disp-07
Rephrase the requirement about well-known file system locations, and
also clarify that by "last path segment" we mean the actual filename.
Added a forward reference from "invalid" to the section that defines
a valid header field.
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. 8 change blocks. 
14 lines changed or deleted 29 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/