Use of the Content-Disposition Header Field
in the Hypertext Transfer Protocol (HTTP)greenbytes GmbHHafenweg 16MuensterNW48155Germanyjulian.reschke@greenbytes.dehttp://greenbytes.de/tech/webdav/
HTTP/1.1 defines the Content-Disposition Response Header,
but points out that it is not part of the HTTP/1.1 Standard.
This specification takes over the definition and registration of
Content-Disposition, as used in HTTP, and clarifies internationalization
considerations.
This specification is expected to replace the definition of Content-Disposition
in the HTTP/1.1 specification, as currently revised by the IETF HTTPbis
working group. See also .
Distribution of this document is unlimited. Although this is not a work
item of the HTTPbis Working Group, comments should be sent to the
Hypertext Transfer Protocol (HTTP) mailing list at ietf-http-wg@w3.org,
which may be joined by sending a message with subject
"subscribe" to ietf-http-wg-request@w3.org.
Discussions of the HTTPbis Working Group are archived at
.
XML versions, latest edits and the issues list for this document
are available from .
A collection of test cases is available at .
HTTP/1.1 defines the Content-Disposition response header in Section 19.5.1 of ,
but points out that is not part of the HTTP/1.1 Standard (Section 15.5):
Content-Disposition is not part of the HTTP standard, but since it is
widely implemented, we are documenting its use and risks for implementors.
This specification takes over the definition and registration of
Content-Disposition, as used in HTTP.
Based on interoperability testing with existing User Agents,
it defines a profile of the
features defined in the MIME variant () of the
header, and also clarifies internationalization
considerations.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in .
This specification uses the augmented BNF notation defined in
Section 2.1 of , including its rules for
linear whitespace (LWS).
If the disposition type matches "attachment" (case-insensitively), the
implied suggestion is that the user agent should not display the response,
but directly enter a "save response as..." dialog.
On the other hand, if it matches "inline", this implies regular processing.
Note that this type may be used when it is desirable to transport
filename information for the case of a subsequent, user-initiated, save
operation.
Other disposition types SHOULD be handled the same way as "attachment"
(, Section 2.8).
Talk about expected behavior, mention security considerations.
Parameters other then "filename" SHOULD be ignored (, Section 2.8).
Both refer to 2183, and also mention: long filenames, dot and
dotdot, absolute paths, mismatches between media type and extension
Section 9 of defines the registration
procedure for new disposition values and parameters.
This document updates the definition of the Content-Disposition HTTP header
in the permanent HTTP header registry (see ).
Content-DispositionhttpstandardIETFthis specification ()TBD.Key words for use in RFCs to Indicate Requirement LevelsHarvard Universitysob@harvard.edu
General
keywordCommunicating Presentation Information in Internet Messages: The Content-Disposition Header FieldNew Century Systemsrens@century.comQUALCOMM Incorporatedsdorner@qualcomm.comDepartment of Computer Sciencemoore@cs.utk.eduHypertext Transfer Protocol -- HTTP/1.1University of California, Irvinefielding@ics.uci.eduW3Cjg@w3.orgCompaq Computer Corporationmogul@wrl.dec.comMIT Laboratory for Computer Sciencefrystyk@w3.orgXerox Corporationmasinter@parc.xerox.comMicrosoft Corporationpaulle@microsoft.comW3Ctimbl@w3.orgApplicability of RFC 2231
Encoding to Hypertext Transfer Protocol (HTTP) Headersgreenbytes GmbHHafenweg 16MuensterNW48155Germanyjulian.reschke@greenbytes.dehttp://greenbytes.de/tech/webdav/Registration Procedures for Message Header FieldsNine by NineGK-IETF@ninebynine.orgBEA Systemsmnot@pobox.comHP LabsJeffMogul@acm.org
Compared to Section 19.5.1 of , the following
normative changes reflecting actual implementations have been made:
According to RFC 2616, the disposition type "attachment" only applies to
content of type "application/octet-stream". This restriction has been
removed, because user agents in practice do not check the content type, and
it also discourages properly declaring the media type.
The definition for the disposition type "inline" (, Section 2.1)
has been re-added with a suggestion for its processing.
This specification requires support for the extended parameter encoding
defined in .
Section 2 of defines several additional
disposition parameters: "creation-date", "modification-date",
"quoted-date-time", and "size". These do not appear to be implemented by
any user agent, thus have been ommitted from this specification.
Mention: RFC 2047, IE, Safari