文字代替图片

Question

转到以下页面，雅虎问答问题所有者提供了问题的屏幕截图。当我点击图片查看它时，，一个有这么多字符的窗口，没有任何意义。我正在使用 Firefox 最新更新。但是这个问题在 Torch 中不存在

Answer 1

响应头包括：

Content-Type: text/plain; charset=utf-8

这是从服务器到浏览器的一条消息，告诉它它发送的数据是某种类型的（text/plain在这种情况下使用 UTF-8 编码），浏览器应该这样解释数据。数据最终显示的方式取决于浏览器，但浏览器应该假设它Content-Type是正确的，而不是查看扩展名（它甚至可能不存在于 URL 中）或尝试分析数据。换句话说，它应该text/plain以同样的方式对待。

Firefox 只做服务器告诉它做的事情。服务器响应不正确（我们目前假设这确实应该是一个图像 - 在这种情况下是正确的，但不是所有情况，因此浏览器无法可靠地检测到这一点）。

如果你真的想要，你可以保存图像并在图像查看器中打开它。您还可以安装一个插件来强制将任何.jpeg以图像结尾的 URL呈现为图像 - 但请注意这可能会破坏其他东西。

归根结底，服务器做错了 - 就 Web 标准而言，FF 通过倾听来做正确的事情。

请注意，RFC 2616 说：

任何包含实体主体的 HTTP/1.1 消息都应该包含一个 Content-Type 头字段，用于定义该主体的媒体类型。当且仅当 Content-Type 字段未给出媒体类型时，接收者可以尝试通过检查其内容和/或用于标识资源的 URI 的扩展名来猜测媒体类型。如果媒体类型仍然未知，则接收者应该将其视为类型“application/octet-stream”。

最近的替换 RFC 2731 指出一些浏览器无论如何都会猜测，但不推荐这样做：

在实践中，资源所有者并不总是正确配置他们的源服务器来为给定的表示提供正确的 Content-Type，结果是一些客户端将检查有效负载的内容并覆盖指定的类型。这样做的客户端有得出错误结论的风险，这可能会暴露额外的安全风险（例如，“权限提升”）。此外，不可能通过检查数据格式来确定发送者的意图：许多数据格式匹配多种仅在处理语义上不同的媒体类型。鼓励实施者提供一种在使用时禁用此类“内容嗅探”的方法。

问题在于，任何任意数据流在扩展名或内容方面都可能看起来像JPEG，但如果源不打算将其作为图像，那么将其解释为这样的解释将是错误的。当Content-Type提供 a 时，浏览器应该相信服务器知道它在做什么，并按照标头指定的方式解释数据。