转到以下页面，雅虎问答问题所有者提供了问题的屏幕截图。当我单击图片查看时，会出现
一个包含大量字符且毫无意义的窗口。我使用的是 Firefox 最新更新。但 Torch 中不存在此问题
答案1
响应标头包括：
Content-Type: text/plain; charset=utf-8
这是服务器向浏览器发送的消息，告知它所发送的数据属于特定类型（text/plain本例中为 UTF-8 编码），浏览器应按此类型解释数据。数据最终的显示方式取决于浏览器，但浏览器应假定数据Content-Type正确，而不是查看扩展名（扩展名可能甚至不存在于 URL 中）或尝试分析数据。换句话说，它应以text/plain同样的方式对待所有数据。
Firefox 只是按照服务器的指令执行。服务器的响应不正确（我们目前假设这实际上是一张图片 - 在这种情况下是正确的，但不是全部情况下，因此浏览器无法可靠地检测到这一点）。
如果你确实想要，你可以保存图片并在图片查看器中打开。你也可以安装一个插件强制将任何以 结尾的 URL.jpeg呈现为图像 - 但请注意，这可能会破坏其他东西。
归根结底，服务器做错了事——而就网络标准而言，FF 通过听取服务器的意见做了正确的事情。
请注意，RFC 2616 指出：
任何包含实体主体的 HTTP/1.1 消息都应包含 Content-Type 标头字段，定义该主体的媒体类型。当且仅当 Content-Type 字段未提供媒体类型时，接收方才可以尝试通过检查其内容和/或用于标识资源的 URI 的名称扩展来猜测媒体类型。如果媒体类型仍然未知，则接收方应将其视为“application/octet-stream”类型。
最新的替代方案 RFC 2731 指出，有些浏览器无论如何都会进行猜测，但不建议这样做：
实际上，资源所有者并不总是正确配置其原始服务器以提供给定表示的正确 Content-Type，结果某些客户端将检查有效负载的内容并覆盖指定的类型。这样做的客户端可能会得出错误的结论，这可能会带来额外的安全风险（例如“特权升级”）。此外，不可能通过检查数据格式来确定发送者的意图：许多数据格式匹配仅在处理语义上不同的多种媒体类型。鼓励实施者提供一种在使用时禁用此类“内容嗅探”的方法。
问题是任意数据流都可能看起来像JPEG 的扩展名或内容，但如果源没有打算认为它是图像，那么将其解释为图像就是错误的。当Content-Type提供时，浏览器应该相信服务器知道它在做什么，并按照标头指定的方式解释数据。