静态服务器可能返回正确的字节,却带上错误的 Content-Type。某个浏览器里页面看起来或许还正常,但下载、样式表、订阅阅读器或安全策略会把同一响应理解成别的东西。公开响应头才是契约;文件名只是服务器配置的输入。
检查有代表性的格式
检查一份 HTML 文档、样式表、SVG、feed 与可下载脚本。包含响应头但丢弃正文:
for path in / /assets/site.css /favicon.svg /index.xml /downloads/check-http-headers.sh; do
curl -sS -D - -o /dev/null "https://www.example.test$path" \
| awk -v path="$path" '
BEGIN { print "== " path }
/^HTTP\// || tolower($1) == "content-type:" || tolower($1) == "x-content-type-options:" { print }
'
done
期望的媒体类型因资源而异,但应该具体且稳定。HTML 通常应包含字符集。CSS 与 SVG 不应被当作泛型二进制数据提供服务。用于下载的 shell 脚本不应被声明为 HTML。
保持 nosniff 一致
X-Content-Type-Options: nosniff 请求支持它的浏览器在脚本与样式目标上尊重声明的类型,而不是猜测。它之所以有用,是因为不匹配会变成可见的失败,而不是因浏览器而异的解读。
该响应头并不能修复一个错误的类型。只有在同时有能证明声明值正确的资源清单时才启用它:
X-Content-Type-Options: nosniff
检查服务器映射
静态服务器通常根据扩展名推导类型。如果某个新扩展名被当作 application/octet-stream 提供服务,先判断这是否有意为之,再决定是否加入全局覆盖。一个窄映射比一条会改变所有响应的规则更容易复核。
在公开主机名上重复这些检查。CDN 或反向代理可能替换掉正确的源站响应头;而一个友好的错误页可能为后缀像 CSS 或 JavaScript 的路径返回 HTML。
来源
- RFC 9110 — HTTP Semantics,表示元数据与
Content-Type,已核验 2026-08-23。 - MDN:
Content-Type,媒体类型与字符集示例,已核验 2026-08-23。 - MDN:
X-Content-Type-Options,nosniff行为,已核验 2026-08-23。