HTTP 基础 · XB 现场笔记

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

Thu, 11 Jun 2026 00:00:00 +0000

静态服务器可能返回正确的字节，却带上错误的 Content-Type。某个浏览器里页面看起来或许还正常，但下载、样式表、订阅阅读器或安全策略会把同一响应理解成别的东西。公开响应头才是契约；文件名只是服务器配置的输入。

后缀不能证明实际收到的内容。应同时检查公开响应的状态、字节与媒体类型；CSS 路径上的 HTML 错误页不能用来测试 MIME 映射。nosniff 让脚本和样式目标上的类型不匹配以可见方式失败。

检查有代表性的格式

检查一份 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

把示例资源路径换成当前发布中确实存在的文件；虚构 CSS 路径返回 HTML 404，并不能测试 MIME 映射。期望的媒体类型因资源而异，但应该具体且稳定。HTML 通常应包含字符集。CSS 与 SVG 不应被当作泛型二进制数据提供服务。用于下载的 shell 脚本不应被声明为 HTML。

该循环只是展示响应头，不会自动断言成功、检视被丢弃的字节，也不会执行浏览器的阻止逻辑。应将资源与发布制品核对，并在浏览器中检查它作为样式表或脚本的实际加载结果。把相同 URL 直接当作文档打开，测试的是另一种请求目标。

保持 nosniff 一致

X-Content-Type-Options: nosniff 请求支持它的浏览器在脚本与样式目标上尊重声明的类型，而不是猜测。在这项 Fetch 检查中，脚本类目标需要 JavaScript MIME 类型，样式目标需要 text/css；类型缺失或无法使用也会失败。这样，不匹配会变成可见的失败，而不是因浏览器而异的解读。

该响应头不能修复错误类型，也不能让任意内容变安全。部署时核对资源清单；若脚本或样式被拒绝，应修复响应，而不是移除保护：

X-Content-Type-Options: nosniff

检查服务器映射

静态服务器通常根据扩展名推导类型。如果某个新扩展名被当作 application/octet-stream 提供服务，先判断这是否有意为之，再决定是否加入全局覆盖。一个窄映射比一条会改变所有响应的规则更容易复核。

在公开主机名上重复这些检查。CDN 或反向代理可能替换掉正确的源站响应头；而一个友好的错误页可能为后缀像 CSS 或 JavaScript 的路径返回 HTML。

来源

RFC 9110 — HTTP Semantics，表示元数据与 Content-Type，已核验 2026-10-15。
MDN: Content-Type，媒体类型与字符集示例，已核验 2026-10-15。
MDN: X-Content-Type-Options，nosniff 行为，已核验 2026-10-15。
WHATWG Fetch 标准，脚本类与样式目标的阻止规则，已核验 2026-10-15。

HEAD 应描述与 GET 相同的表示

Mon, 22 Jun 2026 00:00:00 +0000

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

比较 HEAD 与 GET 之前，先对齐 URL、请求头、发布版本与内容编码。允许省略的字段不能自动判为失败。应保留小 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

在可丢弃的工作目录运行，因为两个头部文件会被覆盖。对齐 URL、请求头与发布版本；压缩协商也应纳入比较，给两个请求发送相同的 Accept-Encoding 值。

HEAD 应描述对应的 GET，但 RFC 9110 允许省略只有在生成内容时才能确定的字段。单独缺少 Content-Length 不代表失败；如果 HEAD 携带它，其值必须是对应 GET 内容的长度，不能因为 HEAD 没有正文就填零。比较时应统一内容编码，调查变化的验证器与类型，而不是要求两份头部逐字节相同。

不要把 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-10-15。
curl manual，--head、--include 与重定向选项，已核验 2026-10-15。

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

Mon, 29 Jun 2026 00:00:00 +0000

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

压缩选择的是表示字节，协商、缓存匹配与验证器必须一致。编码后字节不同就需要不同强标签。下载正文解码后再与制品比较；编码后 Content-Length 不必等于解码文件大小。

让协商可见

当响应可能随 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 指令会协商支持的编码，并且通常对没有合适内容类型或体积过小的响应不做压缩。

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

使用 --compressed 时，curl 自动解码正文，但保存的响应头不会随之改写。若存在 Content-Length，它描述的是编码后内容，未必等于解码后下载文件的大小。应在内容解码后才把校验和与制品比较；HTTP 传输分帧属于另一层。此外，该选项不保证服务器一定压缩，应查看真实响应，尤其是小文件与已经压缩过的文件。

来源

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

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

Mon, 06 Jul 2026 00:00:00 +0000

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

保持表示与内容编码一致，同时核对区间、总大小与实际正文字节。忽略 Range 时，完整的 200 可以合法；续传需要合适的强验证器。

建立完整大小

选择至少 16 字节、测试期间不变的下载文件。在同一个一次性 shell 会话和临时工作目录中依次运行以下片段，保留 url 与 size。显式的 set -eu 会让顺序执行的传输与字节断言失败时停止；HTTP 状态与范围响应头仍需按下文人工核对：

set -eu
url=https://www.example.test/downloads/archive.tar.gz
curl -fsS -H 'Accept-Encoding: identity' -D full.headers -o full.body "$url"
size=$(wc -c < full.body)
test "$size" -ge 16
awk 'tolower($1) ~ /^(content-length:|content-encoding:|etag:|last-modified:|accept-ranges:)$/ { print }' full.headers

确认完整响应为 200，且没有意外的内容编码。这些命令请求 identity 表示，不做自动解压；字节范围针对所选的编码后表示，因此改变编码会使比较失效。Content-Length 可能缺失，所以用完整正文确定大小。

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

请求一个已知区间

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

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

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

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

这里的字节比较专门检查部分正文。合法但大于 16 字节的完整 200 会使比较失败并停止当前 shell 会话；先查看已保存的响应头，再判断是否发生损坏。反过来，完整文件恰好为 16 字节时，即便返回 200 也可能通过 cmp，所以仍需核对状态码与 Content-Range。

测试一个不可能的区间

从完整字节数开始请求：大小为 N 的文件，最后一个有效偏移量是 N−1。与任意写一个大常量不同，这确实超出了已知表示：

set -eu
curl -sS -D - -o /dev/null \
 -H 'Accept-Encoding: identity' -H "Range: bytes=${size}-" "$url"

服务器用 416 Range Not Satisfiable 拒绝无法满足的字节范围时，应附带 Content-Range（例如 bytes */12345）报告当前大小。当服务器忽略 Range 时返回 200 也可能合法，但它必须返回完整表示，而不是一个标签错误的片段。

让验证器留在故事里

续传工具可以用 If-Range 配合强 ETag。不能使用弱 ETag；只有在没有 ETag、且日期符合强验证器条件时，才能使用 HTTP 日期。如果表示已改变，安全响应是完整的最新表示，而不是从两个版本拼接出的字节。在宣称某个下载"可续传"之前，先测试这一行为。

来源

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

缓存头是两套时钟的契约

Thu, 25 Jun 2026 00:00:00 +0000

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

存储、新鲜度与校验是不同问题。根据 URL 的变更方式选择策略，完整保留验证器，并检查共享缓存的变体。

先选变更模型

对于发布之后可能变化的 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 值。

除了新鲜期，还要决定谁可以存储响应。如果共享缓存不能保存面向特定用户的内容，应使用不带参数的 private 指令；浏览器的私有缓存仍可存储。单独使用 no-cache 不提供这项限制。上面的 public 示例适用于可以在用户之间共享的资源，不是个性化响应的默认策略。

同时检查两条路径

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

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 里粘贴编造的验证器。从第一次响应里复制该值，或使用测试夹具。对这里的条件 GET，If-None-Match 匹配时可以通过弱比较返回 304：它允许语义等价，并不一定保证字节完全相同。验证器变化时通常返回新的 200 响应。保留 ETag 的双引号与可能存在的 W/ 前缀。

让中间层可见

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

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

immutable 只在声明的新鲜期内生效，并非永久禁止重校验。版本化 URL 的内容应保持不变，只要旧 HTML 仍可能引用旧资源，就应让它们继续可访问。今天修改响应头不会追溯缩短既有缓存响应的寿命；缓存策略出错时，可能需要新 URL 或缓存系统明确支持的清除操作。

来源

RFC 9111 — HTTP Caching，第 4–5 节，已核验 2026-10-15。
RFC 9110 — HTTP Semantics，第 8 与 13 节，已核验 2026-10-15。
MDN: Cache-Control，指令语义与默认值，已核验 2026-10-15。
RFC 8246 — 不可变响应，immutable 仅在新鲜期内生效，已核验 2026-10-15。

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

Tue, 14 Jul 2026 00:00:00 +0000

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

有意选择迁移或缺失语义。保留所需方法，解析 Location，考虑缓存，并让错误页状态与事实一致。

永久移动并不都等价

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

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

不带 --location 时，curl 不会跟随重定向。相对原 URI 解析 Location：绝对 URI、根相对路径或其他相对引用都可能有效。检查解析后的主机、路径与协议。301/302 允许将 POST 改为 GET；307/308 保留方法。改变状态的方法只能在隔离端点测试。308 可以启发式缓存，但仍受方法与缓存控制限制，因此缓存的迁移结果可能在服务器配置变化后继续存在。

如果目的是在完成操作后展示结果，303 See Other 会指向客户端可用 GET 或 HEAD 获取的另一资源。它不是要求客户端在新地址重放原来的写入操作；应有意选择这种行为，而不是把所有重定向都当作迁移。

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

当服务器找不到当前表示且缺失可能是暂时或未知时，使用 404 Not Found。410 Gone 更强：它表示资源已不可访问，且这种情况很可能是永久的；它并不能说明资源消失的原因。两者都应有帮助人类的正文，但都不应因为自定义错误页成功渲染就返回 200。

404 也可以用于隐藏某个禁止访问的资源是否存在。404 与 410 都可以启发式缓存，但仍受方法与缓存控制约束。应为错误响应明确选择缓存策略：路由修复后，已缓存的缺失结果仍可能继续显示。

这条检查应放在边缘：

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

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

来源

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

robots.txt 与 sitemap 回答不同的问题

Tue, 21 Jul 2026 00:00:00 +0000

两个小文件常被当成安全边界使用，但它们不是。robots.txt 描述爬虫偏好，sitemap 则给搜索系统一份属于该站点的 URL 清单。

发现工具不会授予或拒绝访问。继续检查索引列出的每份 sitemap，验证不止 XML 语法，并按真实错误类别处理 robots 响应。

robots.txt 能做什么、不能做什么

规则发布于源站根路径 /robots.txt，由配合的爬虫读取。它不会保护私有目录、不会从网络上移除 URL，也不能替代认证。不应公开的路由需要服务器授权或网络边界。

让文件保持平实，并测试它的实际位置：

User-agent: *
Disallow:
Sitemap: https://www.example.test/sitemap.xml

文件应为 UTF-8。如果部署会重定向它，请核验你想要的爬虫行为，而不是假设每个客户端都遵循同一条链。

sitemap 增加了什么

sitemap 是一份清单，而不是权限列表。使用单一主机的绝对 URL、正确做 XML 转义，并且只列出你准备发布的规范页面。不要因为某个 URL 存在于构建目录就把它列出。

每份 sitemap 最多包含 50,000 个 URL，未压缩大小不超过 50 MB（52,428,800 字节）；gzip 不会提高该限制。小站可以不用 index，但多语言生成器也可以合理地生成指向各语言 sitemap 的索引。应检查根元素并继续检查列出的各份 sitemap，而不是假设 /sitemap.xml 一定是 URL 集合。把它的 XML 校验通过，并像普通页面一样通过同一 HTTPS 边缘请求它。

curl -fsS https://www.example.test/robots.txt
curl -fsS -o sitemap.xml https://www.example.test/sitemap.xml && \
 xmllint --noout sitemap.xml

把下载与解析分开，避免下载失败被解析成功掩盖。XML 格式正确只代表语法通过；还要验证命名空间、URL 数量、规范主机名，以及列出的页面是否存在。若未安装 xmllint，请在发布它的同一个 CI 环境里解析该 XML。重要的是检查要在文件被替换到边缘之前运行。

robots 的 Disallow 不是可靠的搜索索引删除指令。还要测试错误响应：RFC 9309 在 robots 返回 4xx、表示文件不可用时允许抓取，而网络或服务器错误在最初要求全部禁止。意外返回状态为 200 的 HTML 兜底页，因此可能改变爬虫行为，即使 URL 看起来仍然可访问。

来源

RFC 9309 — Robots Exclusion Protocol，robots 规则、文件位置与 user-agent 匹配，已核验 2026-07-21。
Sitemaps Protocol，sitemap XML 结构与发现，已核验 2026-07-21。

HTTP 方法是对副作用做出的承诺

Thu, 02 Jul 2026 00:00:00 +0000

请求方法说明客户端要求服务器做什么。只读文件源站的契约很窄，但仅凭“静态站点”并不能证明代理或导入的处理器没有暴露写操作。应检查真正服务该资源的路由。

先区分是否请求改变状态与重复请求的预期效果，再检查实际路由。文件处理器边界有明确适用范围，方法支持与 CORS 权限分开判断。

安全与幂等回答不同的问题

GET 与 HEAD 是安全方法：客户端没有请求改变状态的操作。但附带的日志、指标或计费仍可能改变服务器状态。PUT 与 DELETE 按其定义具有幂等语义，却并不安全：重复相同请求的预期效果与执行一次相同。这不要求响应状态码相同，也不意味着每次网络失败后都适合重试。

对只读静态源站：

GET 获取表示。
HEAD 描述对应的 GET，但不携带响应内容。
OPTIONS 询问目标的通信选项；文件处理器可以拒绝它。
POST / PUT / DELETE / PATCH 不应直接落入成功的文件响应，除非另有明确设计的处理器实现其语义。

Caddy 文件处理器的方法边界

Caddy v2.10.2 的文件服务路径接受 GET 与 HEAD，并以 405 和 Allow: GET, HEAD 拒绝其他方法。重定向、缺失路径、错误处理器与其他配置路由可能更早应答或采取不同处理，因此这不是每个静态网站 URL 的统一响应。

原笔记记录过：

$ curl -s -o /dev/null -w 'OPTIONS -> HTTP %{http_code}\n' -X OPTIONS https://www.xbcatm.com/
OPTIONS -> HTTP 405

这里没有保留原始响应日志，本轮审阅也未重现该在线结果。命令只报告状态码，不能证明必需的 Allow 字段存在，需另行检查。405 表示已知方法不被该目标支持；如果服务器根本不识别或未实现该方法，通常应区分为 501 Not Implemented。

HEAD 一致性允许规范规定的省略

HEAD 应描述与 GET 相同的所选表示，同时省略内容。只有生成内容时才能确定的字段可以省略。如果存在 Content-Length，它必须描述采用相同内容编码的对应 GET 内容长度。

原笔记报告过以下比较：

HEAD content-length: 15890
GET bytes read : 15890

这些历史数字不是固定的期望大小，也不是当前验证结果。仅缺少 HEAD 长度是合法的，提供了错误长度才需要调查。成对探针可参考 head-request-parity 笔记；可下载的 check-http-headers.sh 只检视 GET 响应，并不会自动执行这项比较。

拒绝意外写入，同时说明真实契约

对已识别、但目标不允许的方法，返回 405，并以 Allow 列出实际支持的方法。应用路由的这个列表不一定只包含安全方法。不要为被忽略的写请求返回看似合理的 200 页面。

如果浏览器客户端需要 CORS 预检，应明确配置相应 OPTIONS 行为；方法支持与 CORS 权限是两项不同决策。写入拒绝测试应在获准使用的可丢弃夹具上进行，不要因为公共端点看起来静态，就假设向它发送写请求没有影响。

来源

RFC 9110 — HTTP Semantics，安全/幂等方法与 HEAD、405、501 语义，已核验 2026-10-15。
MDN: HTTP 请求方法，方法概览，已核验 2026-10-15。
curl 手册，方法与响应检视选项，已核验 2026-10-15。
Caddy v2.10.2 文件服务器源码，文件选取后的方法拒绝，已核验 2026-10-15。
WHATWG Fetch 标准，CORS 预检处理，已核验 2026-10-15。

验证器决定缓存副本是否仍是答案

Tue, 30 Jun 2026 00:00:00 +0000

缓存可以询问已存储的副本是否仍可使用，而不必每次重新下载正文。它发送验证器；匹配的条件 GET 可以收到 304 Not Modified，表示变化时通常需要新的 200 响应。验证是在命中时省下正文，并非每次请求都省下。

标签仅为示意；假定请求原本成功。GET/HEAD 使用弱比较；HEAD 无正文。匹配既不证明字节相同，也不证明新鲜度。其他方法通常返回 412；If-Range 不能使用弱 ETag。

验证器类型与强度是两回事

ETag 是带双引号的不透明值，可以是强标签（"release-a"），也可以明确标记为弱标签（W/"release-a"）。强比较要求两者都为强标签且值相等；弱比较忽略 W/ 标记，只比较不透明值。即使字节不同，弱标签也可以描述语义等价。

Last-Modified 是 HTTP 日期中精确到秒的时间戳。通常它是弱验证器，除非满足 RFC 9110 第 8.8.2.2 节的条件、可认定为强验证器。不能把所有 ETag 都归为强验证器，也不能无条件把所有时间戳归为弱验证器。

先前的站点观察记录了：

etag: "dkx84jwth7nkc9e"
last-modified: Mon, 24 Aug 2026 13:55:23 GMT

这些是历史值；这里未保留原始响应日志，本轮审阅也未重新检查在线结果。Caddy 文件服务器通常会设置这两个字段，但仍取决于文件元数据与配置。

条件 GET 使用弱比较

把收到的 ETag 原样放进 If-None-Match，保留双引号与可能存在的 W/。原笔记针对上述值报告过 HTTP 304，但展示的请求值没有双引号；该请求文本不符合实体标签语法，不应当作可工作的探针照抄。测试在线端点前应取得当前验证器。

下面无需套接字的练习，展示对单个、已解析标签的比较；它不是完整的 HTTP 头部解析器：

def weak_value(tag):
 return tag[2:] if tag.startswith('W/') else tag

def strong_equal(a, b):
 return not a.startswith('W/') and not b.startswith('W/') and a == b

stored = 'W/"release-a"'
current = '"release-a"'
assert weak_value(stored) == weak_value(current)
assert not strong_equal(stored, current)
assert weak_value(stored) != weak_value('"release-b"')
print("weak match: True; strong match: False; changed tag: no match")

对原本会成功的 GET 或 HEAD，If-None-Match 匹配时返回无正文的 304。其他方法上的同一前置条件为假时，通常返回 412 Precondition Failed。若同时存在 If-None-Match 与 If-Modified-Since，ETag 条件优先。通过 If-Range 做字节范围验证时，不能使用弱 ETag。

重新发布时不要保留误导性的验证器

ETag 不一定是内容哈希。Caddy v2.10.2 的默认文件标签由修改时间与大小生成；替换字节时若两者都保持不变，标签也可能不变。检查实际部署版本与覆盖配置，再让发布流程更新验证器依赖的输入，或采用基于内容的版本标识。

在发布清单中保留字节校验和，并测试未变化与已变化两种响应。校验和不会自动成为服务器的 ETag。304 还需要适用的缓存元数据，让缓存更新已存储的响应；它不只是一个空的成功状态。

来源

RFC 9110 — HTTP Semantics，第 8.8 与 13 节的验证器强度及前置条件，已核验 2026-10-15。
RFC 9111 — HTTP Caching，第 4.3 节的验证与已存储响应更新，已核验 2026-10-15。
MDN: HTTP 条件请求，条件请求概览，已核验 2026-10-15。
Caddy v2.10.2 文件服务器源码，calculateEtag 的输入与默认响应字段，已核验 2026-10-15。

像客户端一样读取活动边缘

Fri, 07 Aug 2026 00:00:00 +0000

HTTP 基础篇的每条笔记各取一纸契约并展示单独的证据。本教程则按顺序走完一次客户端请求触达的完整路径，只用只读命令。目标是区分协议要求与某个服务器的选择，而不是要求所有端点都返回相同状态和头部。

我们全程用 www.xbcatm.com。把它换成你要检查的主机。请求使用 HTTP 安全方法，但仍可能产生访问日志或消耗速率额度。只检查你有权查询的端点。下面输出块是示意，不是当前生产测量。请在一次性工作目录运行 shell 片段，保留错误，并记录时间和客户端版本。

保持所选表示一致，并在各自契约内解读观察结果。本图未查询活动边缘。

1. 先确定方法可以问什么

在读响应体之前，先确定服务器允许你问什么。静态处理器通常支持 GET 和 HEAD，代理也可能实现 OPTIONS。先询问边缘对目标资源的处理：

$ curl -sS --max-time 20 -D - -o /dev/null -w 'OPTIONS -> HTTP %{http_code}\n' -X OPTIONS https://www.xbcatm.com/
HTTP/2 405
allow: GET, HEAD

OPTIONS -> HTTP 405

若服务器识别 OPTIONS、但该资源不支持它，405 Method Not Allowed 是合法答案，且 405 必须携带 Allow。成功的 200 或 204 OPTIONS 响应也可能正确。501 表示服务器未实现该方法。一次 OPTIONS 不能证明其他方法的行为。不要为了测试拒绝而向不熟悉的线上服务发送 POST：它不是安全方法，单有 200 也不能描述其副作用。

2. 读取表示行

第一行告诉你协商出来的交换；头部随后告诉你将要到达的是什么字节。像客户端看到的那样捕获它们、丢弃响应体：

$ curl -sS --max-time 20 -D - -o /dev/null https://www.xbcatm.com/
HTTP/2 200
accept-ranges: bytes
content-length: 15890
content-security-policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:
content-type: text/html; charset=utf-8
etag: "dkx84jwth7nkc9e"
last-modified: Mon, 24 Aug 2026 13:55:23 GMT
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff

三个头部值得停下来。content-type: text/html; charset=utf-8 命中了媒体类型，content-type-and-nosniff 说明为什么它必须描述你真正发送的字节。etag: "dkx84jwth7nkc9e" 交给你强验证器。x-content-type-options: nosniff 限制浏览器的 MIME 处理，尤其是脚本与样式表抓取；它不会验证正文确实是 HTML。每一个都是证据而不是装饰，合在一起是说：该响应声明了应与正文及预期策略比较的元数据。语法上为强 ETag 的值仍是服务器的声明，不是独立的内容哈希证明。

3. 对同一表示比较 HEAD 与 GET

HEAD 使用 GET 的语义，但不带响应正文。服务器应返回相同头部，不过可以省略只有生成内容时才能确定的字段。Content-Length 可省略；若在 HEAD 中发送，它必须等于相应 GET 会发送的内容大小。应在内容稳定时使用相同编码及其他选择头比较：

$ curl -sSI --max-time 20 -H 'Accept-Encoding: identity' https://www.xbcatm.com/ | grep -i content-length
content-length: 15890
$ curl -sS --max-time 20 -H 'Accept-Encoding: identity' https://www.xbcatm.com/ | wc -c
15890

两者一致：都是 15890。这就是 head-request-parity 契约。仅缺少 HEAD 长度不是协议违规。长度不符需要调查，也要排除两次请求之间发生发布、或选中不同表示的可能。没有 pipefail 的 shell 中，传给 wc 的管道可能隐藏 curl 失败；自动关卡应先确认 curl 成功保存正文，再统计文件字节。

4. 用范围请求精确的字节

因为源站知道自己的表示，它可以只服务其中一部分。范围请求要求一个字节区间，只得到那个区间：

$ curl -sS --max-time 20 -D - -o /dev/null -H 'Accept-Encoding: identity' -H 'Range: bytes=0-99' -w 'HTTP %{http_code} bytes=%{size_download}\n' https://www.xbcatm.com/
HTTP/2 206
content-range: bytes 0-99/15890
content-length: 100

HTTP 206 bytes=100

对于至少 100 字节的表示，成功的单范围响应应有 206、匹配的 Content-Range: bytes 0-99/…，以及 100 个内容字节。服务器可合法忽略 Range 并返回完整 200，这不说明它缺少校验器。无法满足的范围可能返回 416。普通 Range 请求不要求 ETag；使用 If-Range 恢复特定表示，或安全拼接部分响应时，才要遵守相关强校验器规则。范围针对所选编码后的字节，因此这里显式选择 identity。

5. 用验证器让缓存重新验证

现在把方法、表示与字节选择通过缓存结合。新鲜的已存响应可能无需检查校验器就可复用。测试重新验证时，应抓取当前响应，并用相同表示选择重放其实际 ETag，不要复制文章里的旧标签：

set -eu
url=https://www.xbcatm.com/
work=$(mktemp -d)
status=$(curl -sS --max-time 20 -H 'Accept-Encoding: identity' \
 -D "$work/headers" -o "$work/body" -w '%{http_code}' "$url")
test "$status" = 200
etag=$(awk 'tolower($1)=="etag:" {sub(/\r$/, ""); sub(/^[^:]*:[ \t]*/, ""); print; exit}' "$work/headers")
test -n "$etag" || { echo 'No ETag: inspect Last-Modified instead' >&2; exit 1; }
curl -sS --max-time 20 -H 'Accept-Encoding: identity' \
 -H "If-None-Match: $etag" -D - -o /dev/null \
 -w 'HTTP %{http_code}\n' "$url"

把此片段作为独立 shell 脚本运行。只有初次传输完整成功且状态为 200，才有可用的已存响应；错误表示也可能有 ETag。若所选表示仍匹配且正常处理成功，预期得到 304，并用更新后的元数据复用这份完整正文。表示变化时，200 完全可能是正确结果。检查结果期间保留临时目录，完成后仅删除此处生成的目录。If-None-Match 使用弱比较，所以 304 不一定证明字节完全一致。新鲜度寿命与当前年龄决定能否直接复用；校验器回答的是另一问题，本身不设定寿命。

6. 协商更小的表示

同样的内容在客户端表明能解压时可以传递更少字节。请求 gzip 并观察正文缩水而语义不变：

$ curl -sS --max-time 20 -H 'Accept-Encoding: identity' -o /dev/null -w 'no-enc: %{size_download} bytes\n' https://www.xbcatm.com/
$ curl -sS --max-time 20 -o /dev/null -H 'Accept-Encoding: gzip' -w 'gzip: %{size_download} bytes\n' https://www.xbcatm.com/
no-enc: 15890 bytes
gzip: 4368 bytes

示例大小展示一种可能的缩减；服务器也可以选择 identity。这是 http-compression-negotiation 笔记的核心：改变选中的表示会改变线上字节，元数据（content-length、encoding）也随之改变。请求压缩的客户端与存储编码形式的缓存必须就选了哪种表示达成一致，否则缓存可能交付不匹配结果。除字节数外，还应检查 Content-Encoding 与 Vary: Accept-Encoding。手工设置 Accept-Encoding 不会让 curl 自动解压；--compressed 才会请求受支持编码并解码响应。应比较解码后的正文来确认内容相同，也不要假定不同编码共用同一个强 ETag。

7. 跟随 URL 变化时的故事

身份变化时，响应应说明故事在哪里继续，而不去猜正文：

$ curl -sS --max-time 20 -o /dev/null -w '%{http_code} -> %{redirect_url}\n' -I http://www.xbcatm.com/ | head -1
308 -> https://www.xbcatm.com/

308 Permanent Redirect 保持方法与故事，正是 redirects-and-status-codes 关心的。无论是永久移动的 301/308，还是由站点处理的 404，状态行都是故事的第一句，应在读正文前先读。

8. 最后让爬虫读地图

边缘也会被根本不请求 HTML 的机器读取。发现机制回答两个不同的问题，robots-and-sitemaps 有说明。确认发现机制指向真实 sitemap：

$ curl -sS --max-time 20 https://www.xbcatm.com/robots.txt
User-agent: *
Disallow:
Sitemap: https://www.xbcatm.com/sitemap.xml

也应抓取 sitemap URL，核对规范主机名与语言 URL。robots.txt 是爬虫指引，不是访问控制；被列入 sitemap 不保证抓取或索引。

所有检查一览

检查	应检查什么	笔记
`OPTIONS` 状态 + Allow	对该资源观察到的方法策略	http-method-semantics
`content-type` + 正文 + `nosniff`	声明的类型与 MIME 处理策略	content-type-and-nosniff
HEAD/GET 元数据	对应表示，允许规定的字段省略	head-parity
Range + Content-Range	观察到的部分传输支持	http-range-requests
抓取的 `ETag` -> 304	条件表示匹配	conditional-requests
308 保留方法	重定向保留故事	redirects-and-status-codes
robots -> sitemap	发现答案不同	robots-and-sitemaps

每一行原来是一条笔记；现在是你可对任意边缘运行的命令。需要细节时读链接的笔记，把这个表留作再次检查时的速查。

来源

WHATWG Fetch Standard，nosniff 处理与请求目标，已核验 2026-10-15。
RFC 9110 — HTTP Semantics，方法、验证器与状态码，已核验 2026-10-15。
RFC 9111 — HTTP Caching，新鲜度与重新验证，已核验 2026-10-15。
RFC 7538 — 308 Permanent Redirect，保留方法的重定向，已核验 2026-10-15。
curl 手册，只读检查选项，已核验 2026-10-15。