【发布时间】:2021-10-01 18:03:45
【问题描述】:
如果响应头包含Content-Disposition: attachment; filename=image.gif,则浏览器会自动保存数据。在这种情况下传递 Content-Type 标头是否有意义?
【问题讨论】:
标签: html http-headers
如果响应头包含Content-Disposition: attachment; filename=image.gif,则浏览器会自动保存数据。在这种情况下传递 Content-Type 标头是否有意义?
【问题讨论】:
标签: html http-headers
是的,如果您知道合适的 Content-Type 标头是什么,这确实有意义,但 NO 没有明确要求。
RFC6266 HTTP 中 Content-Disposition 标头字段的使用
根据原RFC 2616,处置类型“附件”只适用于"application/octet-stream"类型的内容。但是这个限制已经被移除了,因为实际上接收者并不总是检查内容类型,而且它也不鼓励正确声明媒体类型。因此,过去,我们过去必须始终指定
Content-Type:application/octet-stream来强制下载,随着时间的推移,客户端不断发展并开始完全忽略它,如果有处置标头标头。
Content-Type 告诉浏览器如何解释响应,但Content-Disposition: attachment 告诉浏览器将响应视为文件,而不是尝试呈现它。
但并非所有客户端都是网络浏览器,而且并非所有网络浏览器都是平等的。通过同时提供Content-Type,您提供了客户端上下文可以使用的附加信息(如果他们选择),或者如果由于某种原因客户端不理解或不尊重处置标头或其值,它将作为默认值.
通过指定
Content-Type,许多浏览器将使用此信息来确定要应用于另存为对话框的文件类型限制,如果您不这样做,这将特别有用 还指定文件名。
一些现代 Web 客户端(及其扩展程序)将检查 Content-Type 并选择故意将内容传递给为该类型注册的应用程序或扩展程序,而不是始终直接保存到文件中,即使 Content-Disposition是附件。您可能在使用 PDF 查看器时遇到过这种情况。
还有许多嵌入在移动应用程序中的较旧的移动网络客户端和迷你网络浏览器不支持Content-Disposition,或者他们故意绕过它,而是强制直接呈现内容,因此通过提供Content-Type,您可以知道您提供的输出是合理的。
关于 SO 有类似的讨论,但不是直接重复,因为这个问题询问为什么我们可能将其包含在 Content-Type 知道它不太可能被使用。
【讨论】:
Content-Type 是标准的一部分,但Content-Disposition 不是datatracker.ietf.org/doc/html/rfc6266#section-1