HTTP响应头中的content-disposition用途

Question

HTTP响应头中的content-disposition用途

httphttp-headershttpwebresponsehttpresponsecontent-disposition

133

我发现以下ASP.NET代码在从数据库中提取文件时非常有用：

Response.AppendHeader("content-disposition", "attachment; filename=" + fileName);

这使用户可以将文件保存到他们的计算机上，然后决定如何使用它，而不是浏览器试图使用该文件。

响应头中的content-disposition还可以用于做什么其他事情？

- Ronnie Overby

24

请注意，如果文件名包含空格或非ASCII字符，则您的示例代码将出现错误。请参阅RFC 6266获取更多信息。 - Julian Reschke

@JulianReschke，那些被认为是不可打印的 ASCII 字符怎么办？(0 到 0x1F) - Pacerier

阅读RFC 6266（除了在文件名中使用它们是一个坏主意之外；接收者可能会将它们丢弃）。 - Julian Reschke

1

如果您在名称周围使用双引号，则可以使用空格、Unicode等。http://kb.mozillazine.org/Filenames_with_spaces_are_truncated_upon_download - Tony BenBrahim

1

@Ronnie Overby 什么是内容分发？ - divy3993

5个回答

26

看起来，Content-Disposition头最初是为电子邮件而不是网络创建的。（相关RFC链接。）

我猜测Web浏览器可能会响应

Response.AppendHeader("content-disposition", "inline; filename=" + fileName);

在保存时，但我不确定。

- MiffTheFox

6

请参考RFC 6266（在超文本传输协议（HTTP）中使用Content-Disposition头字段），链接如下：https://www.rfc-editor.org/rfc/rfc6266。

- Manish Pai

6

对于asp.net用户，.NET框架提供了一个类来创建内容处理头部：System.Net.Mime.ContentDisposition 基本用法：

var cd = new System.Net.Mime.ContentDisposition();
cd.FileName = "myFile.txt";
cd.ModificationDate = DateTime.UtcNow;
cd.Size = 100;
Response.AppendHeader("content-disposition", cd.ToString());

- onof

1

注意，此类不符合RFC 6266。它在filename参数中进行UTF-8 base64编码，而不是使用RFC 5987编码的filename*参数。没有办法推导或使用fx utils来修复它，几乎所有内容都是不可重写或内部的... .Net fx仍有很长的学习开放性和可扩展性的路要走。在MVC 5.2中，FileResult类对于filename做得更好，但不处理其他参数，如inline，大部分实现也是内部的... - Frédéric

2

这个标头在RFC 2183中定义，所以那可能是开始阅读的最佳位置。

允许的值是与Internet分配号码管理局（IANA）注册的值;他们的值注册表应被视为权威来源。

- NickFitz

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Andrew · Accepted Answer

请注意，RFC 6266 取代了下面引用的 RFC。第7节概述了一些相关的安全问题。

关于 content-disposition 头部的权威性，RFC 1806 和 RFC 2183 是有关内容的。人们也发明了content-disposition hacking。需要注意的是，content-disposition 头部不是 HTTP 1.1 标准的一部分。

HTTP 1.1 标准 (RFC 2616) 还提到了 content disposition 的可能安全副作用：

15.5 Content-Disposition Issues

内容来自 RFC 1806 [35]，常常在 HTTP 中使用的 Content-Disposition
（参见第19.5.1节）头部来源于此，其中存在许多非常严重的安全考虑因素。
Content-Disposition 不是 HTTP 标准的一部分，但由于它被广泛实现，我们为
实现者记录其使用和风险。有关详细信息，请参见 RFC 2183 [49]（更新了 RFC 1806）。