1. Introduction (简介)

RFC 2616定义了Content-Disposition响应头字段 ([RFC2616]的第19.5.1节)，但指出它不是HTTP/1.1标准的一部分 (第15.5节):

Content-Disposition不是HTTP标准的一部分，但由于它被广泛实现，我们为实现者记录其使用和风险。

本规范接管了Content-Disposition在HTTP中的定义和注册。基于与现有用户代理(User Agents, UAs)的互操作性测试，它完整定义了多用途互联网邮件扩展(Multipurpose Internet Mail Extensions, MIME)变体 ([RFC2183]) 中定义的头字段特性的配置文件，并且澄清了国际化方面。

注意: 本文档不适用于通过HTTP传输的有效载荷主体中出现的Content-Disposition头字段，例如使用媒体类型"multipart/form-data" ([RFC2388])时。

2. Notational Conventions (符号约定)

本文档中的关键词"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"和"OPTIONAL"应按照[RFC2119]中的描述进行解释。

本规范使用[RFC2616]第2.1节中定义的增强BNF (ABNF)符号，包括其对隐式线性空白 (Linear Whitespace, LWS)的规则。

3. Conformance and Error Handling (一致性和错误处理)

本规范为Content-Disposition头字段的发送者(通常是HTTP源服务器)和接收者(通常是HTTP用户代理)定义了一致性标准。如果实现符合与其角色相关的所有要求，则认为该实现是一致的。

本规范还使用ABNF和散文要求(第4节)将头字段值的某些形式定义为无效，但它没有定义这些无效字段值的特殊处理。

发送者禁止(MUST NOT)生成无效的Content-Disposition头字段。

接收者可以(MAY)采取措施从无效头字段中恢复可用的字段值，但不应该(SHOULD NOT)完全拒绝消息，除非这是明确希望的行为(例如，实现是一个验证器)。因此，对无效字段的默认处理是忽略它们。