Web

调用方需要的不只是三位数字，还要知道是否收到 HTTP 响应、正文是否完整到达，以及应用结果是否满足预期操作。这是三个不同的问题。二百响应可以按既定契约携带应用层失败，也可能在响应头之后发生传输中断；没有收到响应之前就连接失败，则根本没有 HTTP 状态。诊断和指标应保留这些区别，不能把它们压成一个过于简单的成功标志。 按实际取得的证据分类 HTTP 错误响应仍然是一份响应，其中可能包含有用的表示、认证挑战、请求标识或 Retry-After 字段。有些客户端库会为四开头和五开头状态抛出异常，但仍允许读取这些信息。处理时应先捕获具体 HTTP 异常，再处理更宽泛的传输异常；否则，一个带明确限流提示的四二九，就可能被归成和连接失败完全相同的通用网络错误，丢失下一步判断依据。 HTTP 交换成功也可能只代表业务信封成功传递。例如批处理或 RPC 契约可以返回二百，同时在正文里说明某个子操作失败。应读取文档定义的结构，而不是默认这种响应里的业务全部成功，也不能断言所有此类接口都违反 HTTP。监控需要验证自己承诺监控的结果；如果业务契约要求检查正文，那么只读状态码就没有完成相应检查。 坏掉的样子 在收到响应头时记录状态，可能掩盖随后出现的正文截断。Content-Length、流结束、解压与解析，都影响最后是否得到可用表示。应把已经收到的状态与未完成的传输分别报告，不能因为状态指标已经计入二百，就把只有半份内容的响应视为应用成功。收到响应头，是比完整收到并理解业务结果更早的一个验证点。 是否重试也不能只看第一位数字。四二九表示请求受到限流，可以附带 Retry-After；五零三也可能建议等待。该字段可以使用延迟秒数或 HTTP 日期，但两种形式都没有保证服务器到时一定恢复。客户端应结合服务器提示、有界重试策略、退避和操作语义，避免一遇到错误就立即重放。等待提示不是无限重试的授权，也不是恢复成功的证据。 非幂等请求的响应丢失，可能让业务效果处于未知状态：客户端失去联系之前，服务器也许已经提交。没有合适的幂等契约就重复操作，可能产生重复工作。另一方面，有些四开头错误会随着身份、状态或限流条件改变而变得可恢复。按照整个类别制定“总是重试”或“绝不重试”，会抹掉真正需要用于决策的信息，而不是简化正确的处理逻辑。 状态码本身也不能说明究竟是哪一个组件生成了响应。源站、网关和中间层都可能返回错误，归因时应结合请求标识与相应日志。curl 的 000 一类诊断值，不是注册的 HTTP 响应状态，通常表示没有取得可用的 HTTP 状态。把它当成某种服务器错误，会把连接阶段的问题错误地归到已经收到响应之后的处理阶段。 HTTP：分别判断三类结果。保留的 Mac 试验范围见下文；绘图与本次采纳审阅均未重跑示例。 快速验证 将脚本保存为 status-client.py，使用保留断言的 Python 3.14。五种回环响应和第六个已绑定但未监听的端点，用于检查分类。私有 urllib opener 只为实验关闭代理发现，不更改系统代理。第六个键为 no-response，只检查没有返回 HTTP 状态，不要求特定的拒绝连接错误。保留的 Mac 试验中，该端点始终由实验持有、没有监听，实际观察到的是超时。具体执行设置和证据限制见下文。 ...

UTF-8 用一到四字节编码 Unicode 标量值。ASCII 字符保持熟悉的单字节表示，许多其他字符则需要更长序列。它适合文本交换，却不会让任意字节自动成为有效文本，也不会让每个字节偏移都成为字符边界。正确处理需要编码约定、符合契约的有效性检查，以及对原始字节和已经解码文本的明确区分。 一次读取可能切开字符。保留未完成字节，严格结束校验，并明确计数单位。 坏掉的样子 文件或网络读取可以停在多字节序列中间。每块独立解码，会拒绝原本完整且有效的整个字节流；如果每块都立即替换错误，还可能破坏本应与下一块组成字符的字节。流式解码器需要保留未完成输入，等后续数据到来再处理，并在流结束时检查是否仍有残缺序列。分块边界是传输细节，不是文本天然边界。 UTF-8 的起始与续字节具有可识别模式，但这不使任意切片安全。直接截断编码后的字节串，可能把一个序列切成两半。使用另一种编码成功解码，也不能证明解释正确。Latin-1 能映射每个字节，因此把 UTF-8 误解为 Latin-1，仍会得到合法 Unicode 字符串，却可能已经成为乱码。有效字符串和正确文本不是同一结论。 ...

服务器名称指示 SNI 在 TLS 服务器选择握手参数和证书时，提供客户端希望访问的主机名。本文讨论的是证书认证且没有 early data 的路径，因此选择发生在普通 HTTP 字节发送之前，不是网络上任何字节都还没出现的时候。SNI 只是帮助选择，客户端仍然必须验证返回的证书身份。 同一个地址上的不同决策 客户端把 server_name 放在 ClientHello 中，托管多个名称的服务器可以据此选择证书或安全配置。TLS 1.3 在 ServerHello 之后加密证书消息，所以“选证书和传证书都在加密开始之前完成”不是准确描述。应区分先收到选择提示，和随后如何保护证书及其他握手消息。 SNI 中的 DNS 主机名不等于建立连接时使用的目标 IP，填写名称也不要求实验域名真的经过公共 DNS 解析。RFC 6066 不允许在 HostName 字段直接放入 IPv4、IPv6 字面地址，并规定 DNS 主机名比较不区分大小写。客户端直接按 IP 访问时，可以不发送 DNS SNI，转而验证对应的 IP 身份。 ...

Server-Timing 响应头允许服务端给响应附加具名测量结果，浏览器开发者工具和性能接口随后可以把这些结果与对应资源请求关联起来。当网络瀑布图只能显示等待很久，却无法说明后端是否在查询数据库、渲染页面或执行其他操作时，这类信息很有帮助。但它提供的是服务端选择上报的观测结果，并不是浏览器独立测得这些内部操作的耗时，因此仍然需要理解测量范围和产生位置。 正确的时长语法是 db;dur=42, render;dur=81，建议使用毫秒作为单位。浏览器解析数值，但无法验证发送方实际采用的单位。直接写 db=42，并不是这项协议表达时长的方式。每个指标有名称，也可以带时长和描述参数。生产环境应采用含义稳定的名称，从实际插桩中得到数值。描述可以解释测量对象，但不应包含响应本来不该披露的原始查询、身份编号或内部细节。浏览器能够展示字段，不代表所有调试内容都适合跟随响应对外发送。 让数值对应明确的时间区间 服务端的多个测量值不一定能加成浏览器看到的请求总耗时。它们可能覆盖嵌套操作、相互重叠的工作，也可能只覆盖处理路径的一部分。只有数据库时间与渲染时间的定义允许相加时，加总才有意义。网络传输、测量区间之外的排队、缓存和客户端处理，都可能解释两侧数字的差异，并不一定说明某个时钟有错误。应先弄清每个数值从哪里开始、在哪里结束。 这个响应头也不会自动生成分布式链路。它在单个响应上命名测量结果，并没有自动提供父子关系、跨服务传播或采集器存储。可以用它展示少量对请求有帮助的测量，再通过日志或链路关联获取更深的解释。当响应经过缓存和代理时，还应检查最终交付的响应头，确定这些数字由哪个组件产生。读取一个字段与证明当前源站执行了相应工作，是不同层次的证据。 坏掉的样子 跨源资源存在两个容易混淆的权限边界。CORS 允许脚本读取响应，而 Access-Control-Expose-Headers 可以让 response.headers 暴露 Server-Timing 字段。Timing-Allow-Origin 则控制相应的详细资源计时信息是否可见。安全上下文与浏览器隐私规则还可能进一步限制计时暴露。因此，脚本成功读取响应头，并不能证明 PerformanceResourceTiming.serverTiming 数组一定包含同样的数据。排查时需要分别验证，不能只用其中一个接口有值就推断另一项能力已经成立。 另一个错误，是把解析演示当成真实性能测量。服务端发送固定时长，只能证明浏览器怎样解析这个数字，不能说明处理器实际运行了那么久。同样，计时数组为空，也不能证明服务端没有做任何工作。应先核对来源授权与真实线上响应头，再检查测量代码放置的位置。公开名称与说明还要符合接收对象的范围，避免为了排障而把不该公开的后端结构随响应一起暴露出去。 相同的合成 Server-Timing 可作为响应头读取，却不出现在浏览器性能条目中。原文历史 Chrome 152 对照检查两种暴露权限，不是后端性能测量。 快速验证 将代码保存为 server-timing.py，执行 python3 server-timing.py --serve；此前记录使用 Python 3.14.4；本轮没有重跑套接字或浏览器测试。脚本在两个不同的临时端口上启动本机回环 HTTP 服务，因此它们是不同来源，然后输出待打开的页面地址。页面会请求两份资源，把响应头内容与浏览器解析出的性能条目同时显示出来。结束后按控制键加 C 关闭两个服务；不带服务参数执行时，只检查响应头并退出，不会自动运行浏览器。 ...

Age 是从源站生成或成功验证响应以来，已经经过多少秒的估计值，包含缓存驻留和网络传输时间。它不是对象的创建时间戳，也不是访问次数，更不只是最后一台代理在磁盘上保存副本的时长。要判断这个数字意味着什么，必须同时查看响应的新鲜度策略和实际请求上下文，不能把年龄直接等同于是否允许复用。 先取接收时两种估计的较大值，再加本地驻留时间。新鲜度是严格的年龄比较，并不授权复用。 合并估计时不能重复计时 RFC 9111 定义了接收响应时的两种年龄估计。表观年龄用接收缓存的时钟减去 Date，如果得到负数，就按零处理。校正年龄从收到的 Age 数值出发，再加上发出请求到收到响应之间的时间。缺少 Age 时，这个输入按零参与计算，但并不意味着应当丢掉基于 Date 的另一种估计。 ...

Cookie 的主机与路径作用域，决定哪些目的地有资格收到它的名称和值。缩小这个集合有助于减少暴露，但作用域不是授权，而且 Cookie 并不采用浏览器完整的源边界。本文重点讨论 Domain 与 Path；传输方式、请求语境和浏览器策略还会增加其他限制，不能只凭一个属性就推断最终发送结果。 这里只展示发送资格，不代表授权或最终一定发送。公共后缀及其他 Cookie 规则仍适用；Path 和端口不隔离不可信应用。图示不宣称浏览器一致性验证。 Domain 选择主机，不隔离端口 省略 Domain 会建立 host-only Cookie。从 app.example.com 设置的 Cookie 只匹配这个主机，不匹配 shop.example.com。加入 Domain=example.com，则允许父域与匹配的子域收到它，但仍受其他 Cookie 条件约束。属性处理会忽略一个前导点，它并不是另一种通配符功能。只有那些更宽的接收方确实需要这个值，才应扩大作用域。 ...

懒加载把暂时用不到的工作推迟到更合适的时机。对于 HTML 图片，loading="lazy" 允许浏览器按照自己的策略，等图片接近视口时再发起请求。长文章因此可能减少初始传输量，但这个属性只是调度输入，并不保证每一张尚未进入屏幕的图片都绝对不会下载。能否节省请求，需要观察实际浏览器行为。 让浏览器调度普通图片 原生方式直接使用真实的 src 或 srcset，不必把地址隐藏在自定义属性里，也不必仅为基础懒加载编写滚动处理器。加载距离由浏览器决定，还可能随实现及连接条件调整。作者不能通过 loading 属性直接配置原生距离阈值。使用 IntersectionObserver 的应用方案有另一套控制方式，同时也增加了程序需要承担的调度和兼容责任。 首屏必需的图片应保持及时加载，尤其是主要展示图。如果对决定最大可见内容的图片使用延迟加载，真正有用的画面可能更晚出现。反过来，为刻意延迟的图片添加 preload，也可能提前触发下载，抵消预期节省。应根据图片角色和实测结果选择，而不是给页面所有资源统一贴上同一种策略。 明确填写图片原始 width 和 height，可以让浏览器在下载之前预留宽高比例。响应式样式仍然能够缩小实际宽度，并自动保持高度比例。缺少有效尺寸时，图片最初可能几乎不占空间，既影响哪些内容被认为接近视口，也可能在图片到达后把正文突然推开。图片无法显示时，准确的替代文字仍然是阅读体验的一部分，不能只顾请求数量。 坏掉的样子 只等页面 load 事件结束，可能漏掉尚未完成的懒加载图片。浏览器可以在远处图片未下载完时结束页面加载事件，因此应分别检查图片完成状态、自然尺寸、服务端请求及滚动后的真实显示。请求已经失败与请求尚未开始是不同状态；两者最初都可能没有解码后的像素，不能只凭一项尺寸判断根因。 没有编写页面脚本，不等于在浏览器中禁用了脚本。MDN 说明，作为防跟踪措施，图片的这种延迟行为需要浏览器启用脚本。普通静态 HTML 无须额外编写 JavaScript 就可以使用，但把浏览器脚本整体关闭之后，不能继续假定请求时机完全相同。应按站点实际支持的环境验证，不宣称所有配置都能获得一样的节省。 loading 属性只作用于支持它的元素，不能直接控制任意 CSS 背景图。content-visibility 主要用于跳过部分渲染工作，也不承诺相关网络请求全部延后。快速滚动与慢连接组合时，原生调度仍可能来不及让图片及时到达。评估中需要查看空白占位持续多久以及布局是否稳定，不能把初始请求减少当成用户体验必然改善。 预留空间，延后请求。 依据原文与明确限制静态绘制；未为本图重跑原文夹具。 快速验证 本轮复核没有重新运行 HTTP 服务或浏览器滚动检查；上述 Chrome 结果属于此前记录的运行。 ...

Content-Type 描述发送方打算提供的表示，但它不会检查正文、转换字节，也不保证所有接收方都采取相同的处理方式。可靠的接口需要让序列化结果、媒体类型声明和消费者的预期相互吻合。这个要求不仅适用于成功响应，也适用于认证失败、代理报错和应用异常等不同的返回路径。 描述表示，而不是文件名 对于携带正文的普通响应，application/json 表示 JSON 数据，text/html 表示 HTML。类型描述的是解除内容编码之后的数据格式。因此，一份经过 gzip 压缩的 JSON 响应仍然声明 Content-Type: application/json，同时用 Content-Encoding: gzip 说明压缩。内容编码属于表示的属性，不等于 HTTP 消息如何分帧；例如分块传输编码处理的是另一层问题。修改文件扩展名或响应头都不会自动完成这些转换。 媒体类型由主类型、子类型以及可选参数构成。主类型和子类型不区分大小写，参数是否有意义则取决于对应媒体类型的定义。消费者应使用已有的头字段解析接口，不要把完整字段与一个固定字符串直接比较。同时必须单独检查字段是否存在，因为部分解析器会给缺失类型提供默认值，掩盖服务端漏发元数据的事实。多个相互冲突的类型字段也不是合法的候选列表，而是需要在源站或代理处修正的缺陷。 对于 UTF-8 编码的 HTML，text/html; charset=utf-8 同时描述格式与字符编码。但不能据此给每一种文本格式统一追加字符集参数。RFC 8259 要求非封闭生态系统之间交换的 JSON 使用 UTF-8，而 application/json 的媒体类型注册没有定义 charset 参数。接收方不能靠另加一个参数，就把不符合该交换约定的字节变成合规 JSON。类型参数必须服从格式本身的规定，而不是套用全站通用字符串。 坏掉的样子 常见故障是反向代理把 API 响应替换成 HTML 登录页，却仍返回成功状态码。客户端一上来就调用 JSON 解析器，只能看到语法错误，反而隐藏了“收到另一种表示”这个更有价值的线索。另一种情况恰好相反：应用错误处理器输出 HTML，却沿用了成功路径的 JSON 响应头。这时仅检查声明也会放行无效正文。所以，状态码、响应元数据和实际字节是三个需要一起检查的证据。 ...