Skip to main content

4. Header Field Definition (头字段定义)

Content-Disposition响应头字段用于传达关于如何处理响应有效载荷的附加信息，并且还可用于附加额外的元数据，例如在本地保存响应有效载荷时使用的文件名。

4.1. Grammar (语法)​

content-disposition = "Content-Disposition" ":"
                       disposition-type *( ";" disposition-parm )

disposition-type    = "inline" | "attachment" | disp-ext-type
                    ; 不区分大小写
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           = <token中的字符，后跟"*">

在[RFC2616]中定义:

token         = <token, 定义于[RFC2616]第2.2节>
quoted-string = <quoted-string, 定义于[RFC2616]第2.2节>
value         = <value, 定义于[RFC2616]第3.6节>
              ; token | quoted-string

在[RFC5987]中定义:

ext-value   = <ext-value, 定义于[RFC5987]第3.2节>

具有相同参数名称的多个实例的Content-Disposition头字段值是无效的。

请注意，由于隐式线性空白的规则([RFC2616]第2.1节)，可选空白可以出现在单词(token或quoted-string)和分隔符之间。

此外，请注意，用于ext-value的格式允许指定自然语言(例如，"en")；这对于文件名的用处有限，并且可能会被接收者忽略。

4.2. Disposition Type (处置类型)​

如果处置类型匹配"attachment"(不区分大小写)，这表示接收者应该提示用户在本地保存响应，而不是正常处理它(根据其媒体类型)。

另一方面，如果它匹配"inline"(不区分大小写)，这意味着默认处理。因此，处置类型"inline"仅在使用附加参数(例如下面的filename)增强时才有用。

未知或未处理的处置类型应该(SHOULD)由接收者以与"attachment"相同的方式处理(另见[RFC2183]第2.8节)。

4.3. Disposition Parameter: 'Filename' (处置参数: 文件名)​

参数"filename"和"filename*"(不区分大小写匹配)提供关于如何构造用于存储消息有效载荷的文件名的信息。

根据处置类型，此信息可能会立即使用(在"attachment"处置类型导致的"另存为..."交互中)，或稍后使用(例如，当用户决定保存当前显示的页面内容时)。

参数"filename"和"filename*"仅在于"filename*"使用[RFC5987]中定义的编码，允许使用ISO-8859-1字符集 ([ISO-8859-1])中不存在的字符。

许多早于本规范的用户代理实现不理解"filename*"参数。因此，当单个头字段值中同时存在"filename"和"filename*"时，接收者应该(SHOULD)选择"filename*"并忽略"filename"。这样，发送者可以通过同时发送更具表现力的"filename*"参数和"filename"参数作为旧版接收者的回退，来避免针对特定用户代理的特殊情况处理(示例见第5节)。

接收者必须(MUST)将指定的文件名仅视为建议，因此在提取所需信息时必须非常小心。特别是:

  • 接收者禁止(MUST NOT)能够写入除其特别授权的位置之外的任何位置。为了说明问题，考虑能够覆盖众所周知的系统位置(例如"/etc/passwd")的后果。实现此目的的一种策略是永远不要信任filename参数中的文件夹名称信息，例如通过剥离除最后一个路径段之外的所有内容，并仅考虑实际文件名(其中"路径段"是由路径分隔符字符""和"/"分隔的字段值的组成部分)。

  • 许多平台不使用Internet媒体类型 ([RFC2046])在文件系统中保存类型信息，而是依赖于文件扩展名。信任服务器提供的文件扩展名可能会在稍后打开保存的文件时引入权限提升(考虑".exe")。因此，使用文件扩展名来确定媒体类型的接收者必须(MUST)确保使用的文件扩展名是安全的，最好与接收到的有效载荷的媒体类型匹配。

  • 接收者应该(SHOULD)剥离或替换已知会在用户界面和文件名中引起混淆的字符序列，例如控制字符以及前导和尾随空白。

  • 接收者需要注意的其他方面是在文件系统或shell命令中具有特殊含义的名称，例如"."和".."、"~"、"|"，以及设备名称。接收者应该(SHOULD)忽略或替换此类名称。

注意: 许多用户代理在使用quoted-string形式时不能正确处理转义字符""。此外，一些用户代理错误地尝试对"百分号"转义进行反转义(见附录C.2)，因此可能会错误解释包含百分号字符后跟两个十六进制数字的文件名。

4.4. Disposition Parameter: Extensions (处置参数: 扩展)​

为了启用未来的扩展，接收者应该(SHOULD)忽略无法识别的参数(另见[RFC2183]第2.8节)。

4.5. Extensibility (可扩展性)​

请注意，[RFC2183]的第9节为处置值和处置参数定义了IANA注册表。此注册表由使用Content-Disposition的不同协议共享，例如MIME和HTTP。因此，并非所有注册的值在HTTP的上下文中都有意义。

Last updated on