Http · XB 现场笔记

Content-Type 应描述你实际发送的字节

Sun, 23 Aug 2026 00:00:00 +0000

静态服务器可能返回正确的字节，却带上错误的 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。

Cookie 作用域应比应用边界更窄

Sun, 23 Aug 2026 00:00:00 +0000

Cookie 依据浏览器规则附加到请求，而不是依据最初设置它的服务器组件。宽泛的 Domain 或 Path 会把状态暴露给无关的路由或子域名，而缺失传输与脚本限制则会放大其他失败造成的损害。

当省略 Domain 时，Cookie 被限定在设置它的主机内。加上 Domain=example.test 则它也允许发给符合条件子域名。只有多个主机确实共享同一应用与信任边界时才使用更宽的形式。

检视响应而不把真实 Cookie 值打进日志：

curl -sS -D - -o /dev/null https://app.example.test/login \
 | awk '
 tolower($1) == "set-cookie:" {
 sub(/Set-Cookie: [^;]*/, "Set-Cookie: [value redacted]")
 print
 }
 '

一起复核这些属性

Secure 把传输限制在安全上下文中。
HttpOnly 通过 document.cookie 阻止 JavaScript 访问；它不会阻止浏览器发送该 Cookie。
SameSite 影响跨站请求，必须匹配应用的导航或嵌入需求。
Path 控制发送时机，但它不是同一主机上不同应用之间的授权边界。

在现代浏览器中，SameSite=None 的 Cookie 还需要 Secure。避免把这对组合复制进不需要跨站用途的应用。

在其约束契合时使用前缀

__Secure- 与 __Host- 等 Cookie 名称前缀，让支持的浏览器强制额外的要求。__Host- Cookie 必须使用 Secure、省略 Domain、并使用 Path=/，这使主机专用的意图变得显式。

用相同作用域测试删除

删除 Cookie 需要一条与存储它所用属性匹配的过期指令，尤其是名称、域名与路径。只清除一个变体的登出可能让另一个 Cookie 仍然有效。

一个真正静态的文档站点通常没有理由设置应用 Cookie。核验公共响应不含 Set-Cookie 响应头，而不是为站点并不需要的存储增加一个同意界面。

来源

RFC 6265 — HTTP State Management Mechanism，Cookie 存储与作用域，已核验 2026-08-23。
MDN: Set-Cookie，属性与名称前缀，已核验 2026-08-23。

HEAD 应描述与 GET 相同的表示

Sun, 23 Aug 2026 00:00:00 +0000

HEAD 方法请求服务器对 GET 会返回的响应，但不会传输响应内容。它适合需要状态、验证器、类型或长度的检查，但前提是元数据与真实的 GET 路径保持一致。

比较规范化后的响应头集合

Date 这类动态响应头会随请求不同而变化。只比较描述所选表示的那些字段：

url=https://www.example.test/downloads/manual.pdf

curl -sS -I "$url" > head.headers
curl -sS -D get.headers -o /dev/null "$url"

for file in head.headers get.headers; do
 printf '== %s\n' "$file"
 awk '
 /^HTTP\// ||
 tolower($1) ~ /^(content-type:|content-length:|content-encoding:|cache-control:|etag:|last-modified:|vary:)$/ { print }
 ' "$file"
done

两次请求应选择相同的状态码与表示元数据。压缩协商也应纳入比较：给两个请求发送相同的 Accept-Encoding 值。

不要把 HEAD 当作唯一的发布检查

服务器可能在文件缺失、不可读或被截断时仍合成看似合理的响应头。在冒烟测试里保留一个小的 GET 并核验其正文或校验和。HEAD 降低了传输成本，但并不能证明有效载荷存在。

显式检查重定向

不使用 --location 时，curl -I 报告第一个响应，适合测试重定向策略；使用 --location 时报告最终链，适合测试目标地址。请记录这条命令回答的是哪个问题：

curl -sS -I --max-redirs 0 https://old.example.test/manual
curl -sS -I --location https://old.example.test/manual

把方法相关的失败视为配置缺陷

一个对 GET 返回 200、对 HEAD 返回 405 或 404 的静态页面，通常暴露出代理或路由的不一致。应当修复方法处理，而不是教监控系统忽略它——除非端点契约刻意不允许 HEAD。

来源

RFC 9110 — HTTP Semantics，HEAD 方法语义，已核验 2026-08-23。
curl manual，--head、--include 与重定向选项，已核验 2026-08-23。

范围请求应证明选中了哪些字节

Sun, 23 Aug 2026 00:00:00 +0000

范围请求让客户端请求表示的一部分。媒体播放器、可断点续传的下载工具与诊断客户端会用到它，但服务器如果错误地声明或返回范围，就可能产生静默损坏，而不是干净的失败。

建立完整大小

抓取完整表示的响应头，并记录其长度与验证器：

url=https://www.example.test/downloads/archive.tar.gz
curl -sS -D full.headers -o /dev/null "$url"
awk 'tolower($1) ~ /^(content-length:|etag:|last-modified:|accept-ranges:)$/ { print }' full.headers

Accept-Ranges: bytes 是显式信号，但缺少这个头并不能证明范围请求不受支持。去实际请求一次。

请求一个已知区间

请求开头 16 字节，同时保留响应头与正文：

curl -sS -D range.headers -o range.body \
 -H 'Range: bytes=0-15' "$url"

wc -c range.body
awk 'tolower($1) ~ /^(content-range:|content-length:|etag:)$/ || /^HTTP\// { print }' range.headers

成功的字节范围响应应使用 206 Partial Content。Content-Range 应指出 0-15 与完整表示长度，而正文应正好包含 16 个字节。

测试一个不可能的区间

请求超出已知末尾的字节：

curl -sS -D - -o /dev/null \
 -H 'Range: bytes=999999999-' "$url"

对无法满足的字节范围，416 Range Not Satisfiable 加一个类似 bytes */12345 的 Content-Range 值会暴露真实长度。当服务器忽略 Range 时返回 200 也可能合法，但它必须返回完整表示，而不是一个标签错误的片段。

让验证器留在故事里

续传工具可以用 If-Range 配合强验证器或日期。如果表示已改变，安全响应是完整的最新表示，而不是从两个版本拼接出的字节。在宣称某个下载"可续传"之前，先测试这一行为。

来源

RFC 9110 — HTTP Semantics，范围单位、部分响应与 Content-Range，已核验 2026-08-23。
curl manual，--range 与响应头选项，已核验 2026-08-23。

缓存头是两套时钟的契约

Sat, 22 Aug 2026 00:00:00 +0000

缓存不是一个单一开关。一个响应既有一个由缓存作出的新鲜度决策，也有与源站之间的校验对话。把这两种想法混在一起，会得到陈旧内容或多余请求。

先选变更模型

对于发布之后可能变化的 HTML 文档，Cache-Control: no-cache 通常比 no-store 更接近正确起点。no-cache 允许存储，但要求缓存复用前先校验；no-store 则要求缓存完全不存储。当你想要条件请求与廉价的 304 Not Modified 时，这个区别很关键。

对类似 app.4f2c.js 这种带指纹的资源，URL 在字节变化时也随之改变，此时一个较长的新鲜度生命周期是合理的：

Cache-Control: public, max-age=31536000, immutable

但对一个内容可能被原地替换的稳定 URL，该策略不安全。如果 URL 稳定，应优先使用较短的生命周期，并搭配实体标签（ETag）或有意义的 Last-Modified 值。

同时检查两条路径

发一次普通请求，再发一次条件请求。各服务器的具体标志可能不同，但你想要的证据是稳定的：

curl -sS -D - -o /dev/null https://www.example.test/
curl -sS -D - -o /dev/null \
 -H 'If-None-Match: "copy-a-real-etag-from-the-first-response"' \
 https://www.example.test/

不要在 runbook 里粘贴编造的验证器。从第一次响应里复制该值，或使用测试夹具。只有服务器能证明所选表示未变化时，成功的重校验才应返回 304。

让中间层可见

Age、Vary 与 cache-control 指令说明了为什么两个客户端可能得到不同结果。如果响应随 Accept-Encoding、语言或其他请求字段变化，该维度应进入 Vary；否则共享缓存可能复用错误的表示。

有意义的发布检查不是"扫描器找到了缓存头"，而是"该头与替换策略匹配，且条件请求的行为符合文档说明"。

来源

RFC 9111 — HTTP Caching，第 4–5 节，已核验 2026-08-22。
RFC 9110 — HTTP Semantics，第 8 与 13 节，已核验 2026-08-22。
MDN: Cache-Control，指令语义与默认值，已核验 2026-08-22。

压缩会改变所选中的 HTTP 表示

Sat, 22 Aug 2026 00:00:00 +0000

压缩节省传输字节，但也制造了资源的另一种表示。客户端用 Accept-Encoding 声明可接受的内容编码；服务器用 Content-Encoding 描述实际应用的编码。

让协商可见

当响应可能随 Accept-Encoding 变化时，把该请求字段写进 Vary。这告诉共享缓存：压缩响应与 identity 响应不是可互换的缓存条目。

不要只检查一个浏览器请求，而是比较两条路径：

curl -sS -D - -o /dev/null \
 -H 'Accept-Encoding: identity' https://www.example.test/
curl -sS --compressed -D - -o /dev/null \
 https://www.example.test/

检查 Content-Encoding、Vary、Content-Length（如存在）与验证器。服务器可为不同编码的表示使用不同实体标签；重要的是条件请求一致地验证同一个所选表示。

压缩合适的内容

HTML、CSS、JSON、XML、SVG 等文本格式通常适合压缩；已经压缩过的格式未必适合。Caddy 的 encode 指令会协商支持的编码，并且通常对没有合适内容类型或体积过小的响应不做压缩。

不要为了满足某个评分而加压缩。测量一个有代表性的响应，确认边缘返回预期的头，并核验可下载文件在传输解码后仍保留正确的内容类型与校验和。

来源

RFC 9110 — HTTP Semantics，内容编码与 Vary，已核验 2026-08-22。
Caddy encode 指令，内容编码选择与协商，已核验 2026-08-22。
curl manual，--compressed，已核验 2026-08-22。

重定向与错误码应保留故事的完整性

Sat, 22 Aug 2026 00:00:00 +0000

HTTP 状态码是接口的一部分。浏览器可能渲染出一个友好的页面，但监控、爬虫、缓存与 API 客户端也需要状态码与响应头来讲述同一个故事。

永久移动并不都等价

308 Permanent Redirect 在保留请求方法的同时，传达资源有了新的永久 URI。这对发送 POST、PUT 或其他非 GET 方法的客户端很重要。旧页面到新页面的重定向用 GET 很容易测试；端点的迁移则必须用真实调用方实际使用的方法来测试。

curl -sS -D - -o /dev/null --max-redirs 0 \
 https://old.example.test/api/item

检查 Location 是否为绝对地址或正确锚定、目标是否是预期主机，以及响应是否被静默降级为临时重定向。308 默认可缓存，因此只有在有意识的迁移计划时才改动它。

区分"缺失"与"被移除"

当服务器找不到当前表示且缺失可能是暂时或未知时，使用 404 Not Found。410 Gone 更强：它表示资源被有意移除且不太可能回归。两者都应有帮助人类的正文，但都不应因为自定义错误页成功渲染就返回 200。

这条检查应放在边缘：

curl -sS -o /tmp/missing.html -w '%{http_code} %{url_effective}\n' \
 https://www.example.com/a-route-that-does-not-exist

在错误路径上也应保留安全响应头。安全头、有用的内容类型与正确的状态码，比一个装饰性的错误动画更有价值。

来源

RFC 9110 — HTTP Semantics，第 15 与 13 节，已核验 2026-08-22。
RFC 7538 — 308 Permanent Redirect，第 3 节，已核验 2026-08-22。
curl manual，状态与重定向检查标志，已核验 2026-08-22。

Http · XB 现场笔记

Content-Type 应描述你实际发送的字节

检查有代表性的格式

保持 nosniff 一致

检查服务器映射

来源

Cookie 作用域应比应用边界更窄

偏好仅主机 Cookie

一起复核这些属性

在其约束契合时使用前缀

用相同作用域测试删除

让静态站点免 Cookie

来源

HEAD 应描述与 GET 相同的表示

比较规范化后的响应头集合

不要把 HEAD 当作唯一的发布检查

显式检查重定向

把方法相关的失败视为配置缺陷

来源

范围请求应证明选中了哪些字节

建立完整大小

请求一个已知区间

测试一个不可能的区间

让验证器留在故事里

来源

缓存头是两套时钟的契约

先选变更模型

同时检查两条路径

让中间层可见

来源

压缩会改变所选中的 HTTP 表示

让协商可见

压缩合适的内容

来源

重定向与错误码应保留故事的完整性

永久移动并不都等价

区分"缺失"与"被移除"

来源