这个问题是关于浏览器行为以及从 html、js 或 css 文件中链接、导入、包括或 ajaxing css、js、图像和其他资源的协议规范。
在不同浏览器中测试静态文件和压缩内容交付时，我发现如果您脱离惯例，某些浏览器的行为会有所不同。例如，如果您不为所有内联 css 和 js 等文件发送 Content-Disposition: inline; 标头，IE6 会产生问题，并且如果您使用文件扩展名 .gz ，最新版本的 safari 无法正确处理预压缩的 gzip CSS 文件main-styles.css.gz.
我的问题是关于 Content-Type 响应标头的浏览器行为。由于<link>、<script> 和<img> 标签已经合理地指定了资源的内容类型，是否可以安全地跳过此标头，或者某些浏览器是否出于某些历史原因需要它？
【问题讨论】：
标签： http browser cross-browser
向后兼容是必需的。
例如：Internet Explorer 10 需要 Content-Type:image/svg+xml 才能渲染任何 svg 文件
IE10、IE9 和其他浏览器可能总是需要 Content-Type 标头。
【讨论】：
我在 java 中遇到了一个问题，我尝试通过库 chrriis.dj.nativeswing.swtimpl.components.JWebBrowser 发布一些数据，该库基本上在 Java 程序中显示 Internet Explorer。但是后端的简单 php 脚本不会解析我的后期数据。 （使用 WebBrowserNavigationParameters 在导航到某个页面时设置发布数据）我终于发现必须为 php 设置 Content-Type 标头才能正确粘贴发布数据。 （默认情况下未设置。）将其设置为 Content-Type: application/x-www-form-urlencoded 并且一切正常。所以，我猜想在将数据发布到 php 时总是应该设置 Content-Type。
【讨论】：
简而言之，不，这不是必需的。但这是推荐的。
我所知道的大多数浏览器都会正确处理<link>、<script> 和<img>，如果它们没有与标头一起发送，但没有真正好的理由不发送标头。基本上，没有Content-Type 标头，浏览器就可以根据内容进行尝试和猜测。
来自 RFC2616：
Content-Type 指定底层数据的媒体类型。
内容编码可用于指示任何附加内容
应用于数据的编码，通常用于数据目的
压缩，这是所请求资源的属性。有
没有默认编码。任何包含实体主体的 HTTP/1.1 消息都应该包含一个
定义该主体的媒体类型的 Content-Type 标头字段。如果
并且仅当 Content-Type 字段未给出媒体类型时，
接收者可以尝试通过检查其
来猜测媒体类型 用于标识
的 URI 的内容和/或名称扩展名 资源。如果媒体类型仍然未知，接收者应该
将其视为“application/octet-stream”类型。
关于关键字应该，在 RFC2119 中指定：
应该：这个词，或形容词“推荐”，意味着那里
在特定情况下可能存在忽略a的正当理由
特定项目，但必须了解全部含义并
在选择不同的课程之前仔细权衡。
【讨论】：