MAY"> MUST"> MUST NOT"> OPTIONAL"> RECOMMENDED"> REQUIRED"> SHALL"> SHALL NOT"> SHOULD"> SHOULD NOT"> ]> greenbytes GmbH

Hafenweg 16 MuensterNW48155 Germany julian.reschke@greenbytes.de http://greenbytes.de/tech/webdav/

Umbrella issue for editorial fixes/enhancements. HTTP/1.1 defines the Content-Disposition Response Headerresponse header field, 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 headerresponse header field in , but points out that it is not part of the HTTP/1.1 Standard (): 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 headerheader field, 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 , including its rules for linear whitespace (LWS).

content-disposition = "Content-Disposition" ":" disposition-type *( ";" disposition-parm ) disposition-type = "inline" | "attachment" | disp-ext-type ; case-insensitive disp-ext-type = token disposition-parm = filename-parm | disp-ext-parm filename-parm = "filename" "=" value | "filename*" "=" ext-value disp-ext-parm = token "=" value | ext-token "=" ext-value ext-token = <the characters in token, followed by "*">

Defined in : token = <token, defined in > value = <value, defined in >

Defined in : ext-value = <ext-value, defined in >

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" ().

Talk about expected behavior, mention security considerations.

Parameters other thenthan "filename" &SHOULD; be ignored ().

Direct UA to show "save as" dialog, with a filename of "foo.html": Content-Disposition: Attachment; filename=foo.html

Direct UA to behave as if the Content-Disposition headerheader field wasn't present, but to remember the filename "foo.html" for a subsequent save operation: Content-Disposition: INLINE; FILENAME= "foo.html"

Both refer to 2183, and also mention: long filenames, dot and dotdot, absolute paths, mismatches between media type and extension

defines the registration procedure for new disposition values and parameters. This specification does not introduce any changes to the registration procedures for disposition values and parameters that are defined in .

This document updates the definition of the Content-Disposition HTTP headerheader field in the permanent HTTP headerheader field registry (see ). Content-Disposition http standard IETF this specification ()

TBD.

Harvard University

sob@harvard.edu

General keyword New Century Systems

rens@century.com

QUALCOMM Incorporated

sdorner@qualcomm.com

Department of Computer Science

moore@cs.utk.edu

University of California, Irvine

fielding@ics.uci.edu

W3C

jg@w3.org

Compaq Computer Corporation

mogul@wrl.dec.com

MIT Laboratory for Computer Science

frystyk@w3.org

Xerox Corporation

masinter@parc.xerox.com

Microsoft Corporation

paulle@microsoft.com

W3C

timbl@w3.org

greenbytes GmbH

Hafenweg 16 MuensterNW48155 Germany julian.reschke@greenbytes.de http://greenbytes.de/tech/webdav/

greenbytes GmbH

Hafenweg 16 MuensterNW48155 Germany julian.reschke@greenbytes.de http://greenbytes.de/tech/webdav/

Nine by Nine

GK-IETF@ninebynine.org

BEA Systems

mnot@pobox.com

HP Labs

JeffMogul@acm.org

Compared to , 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" () has been re-added with a suggestion for its processing. This specification requires support for the extended parameter encoding defined in .

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

Adjust terminology ("header" -> "header field"). Update rfc2231-in-http reference.