HTTP · XB 现场笔记

nginx 验证器是否可靠，取决于表示身份是否准确

Thu, 17 Feb 2028 00:00:00 +0000

验证器让接收方询问：自己保存的表示，是否仍与当前选中的表示相符。条件 GET 验证成功时，可以返回没有正文的 304，避免重新传输内容。新鲜度是另一个决定，它控制已存响应何时能直接复用而不发送这次请求。ETag 本身不指定缓存寿命，304 也不是一份替代正文；客户端需要保留原响应，才能利用成功验证的结果。

文章描述 nginx 1.28.0 的固定版本反例：修改时间与长度相同，可能让不同字节共享 ETag。本次核验未重新运行该实验。

坏掉的样子

把所有 ETag 都叫作正文哈希，会掩盖 nginx 的一个重要实现细节。在固定版本 1.28.0 的静态文件实现中，生成的标签组合了修改时间和内容长度，并不计算文件内容哈希。如果替换字节时保留这两个输入，就可能保留同一个标签。于是，持有不同旧字节的客户端仍收到看似成功的验证，错误不能仅靠“响应里有 ETag”来排除。

强弱验证器适用于不同比较。对于需要字节身份的用途，强验证器必须能区分表示数据变化；弱验证器则可以把字节不同、但被认为语义等价的表示归在一起。W/ 并不是“接受字节等价变化”的标志，也不意味着这个标签适用于所有前提条件或字节范围续传。使用哪种比较，需要依据具体请求条件，而不是凭标签外观猜测。

条件请求不保证省掉应用计算。服务器可能先生成表示，之后才判断验证器是否匹配。这个静态 nginx 示例根本没有应用渲染器。较小的响应在这里证明节省了正文传输，却不能证明数据库查询、渲染成本或回源请求数必然减少。评估优化效果时，应把实际减少的数据传输和实际减少的后台工作分别测量。

快速验证

下文结果保留自来源中的实验报告，并非本次新运行的 Docker 或 nginx 结果。把脚本保存为 check-validators.py，先取得固定摘要的 nginx 镜像，再用 Python 和 Docker 运行。它通过宿主回环提供一个可丢弃的四字节静态文件，实测 nginx 版本为 1.28.0。实验只控制容器内文件的时间属性，不修改宿主时间，也不修改共享 Docker 虚拟机时钟：

from contextlib import contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import http.client,json,socket,subprocess,time,uuid

NGINX='nginx@sha256:552e7481ca93ffccd046aa658dbbed22caefbc09c66fa7cd247cbb90b8a5c609'
PYTHON='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def wait(predicate):
 deadline=time.monotonic()+15
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except OSError:pass
 time.sleep(.1)
 raise AssertionError('fixture did not become ready')

@contextmanager
def lab(configuration,files=None,backend=None):
 name='xbcatm-nginx-'+uuid.uuid4().hex[:10];tags=[name+':proxy',name+':backend'];containers=[name+'-proxy',name+'-backend']
 try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'files').mkdir();(root/'nginx.conf').write_text(configuration)
 for path,content in (files or {}).items():
 target=root/'files'/path;target.parent.mkdir(parents=True,exist_ok=True)
 target.write_bytes(content if isinstance(content,bytes) else content.encode())
 docker('network','create',name)
 if backend is not None:
 (root/'backend.py').write_text(backend)
 (root/'backend.Dockerfile').write_text(f'FROM {PYTHON}\nCOPY backend.py /backend.py\nCMD ["python", "/backend.py"]\n')
 docker('build','--network','none','-f',str(root/'backend.Dockerfile'),'-t',tags[1],str(root))
 docker('run','-d','--name',containers[1],'--network',name,'--network-alias','backend',tags[1])
 wait(lambda:docker('exec',containers[1],'python','-c','import socket;s=socket.create_connection(("127.0.0.1",8081),timeout=.5);s.close()',check=False).returncode==0)
 (root/'Dockerfile').write_text(f'FROM {NGINX}\nCOPY nginx.conf /etc/nginx/nginx.conf\nCOPY files /srv\n')
 docker('build','--network','none','-t',tags[0],str(root))
 docker('run','--rm','--network',name,tags[0],'nginx','-t')
 docker('run','-d','--name',containers[0],'--network',name,'-p','127.0.0.1::8080',tags[0])
 details=json.loads(docker('inspect',containers[0]).stdout)[0]
 binding=details['NetworkSettings']['Ports']['8080/tcp'][0];assert binding['HostIp']=='127.0.0.1';port=int(binding['HostPort'])
 def ready():
 connection=socket.create_connection(('127.0.0.1',port),timeout=.5);connection.close();return True
 wait(ready)
 def request(path,method='GET',headers=None,body=None):
 connection=http.client.HTTPConnection('127.0.0.1',port,timeout=5)
 try:
 connection.request(method,path,body=body,headers=headers or {})
 response=connection.getresponse();return response.status,{k.lower():v for k,v in response.getheaders()},response.read()
 finally:connection.close()
 request.port=port
 yield containers[0],request
 finally:
 docker('rm','-f',*containers,check=False);docker('image','rm',*tags,check=False);docker('network','rm',name,check=False)

def config(locations,extra=''):
 return 'worker_processes 1;\nerror_log /tmp/error.log notice;\nevents {}\nhttp {\naccess_log off;\n'+extra+'\nserver { listen 8080; root /srv;\n'+locations+'\n}\n}\n'
files={'asset.txt':'AAAA','noetag.txt':'AAAA'}
with lab(config('location = /noetag.txt { etag off; }'),files) as (proxy,request):
 def timestamp(value):docker('exec',proxy,'touch','-m','-d','@'+str(value),'/srv/asset.txt')
 timestamp(1577836800)
 status,headers,body=request('/asset.txt');assert status==200 and body==b'AAAA'
 tag=headers['etag'];modified=headers['last-modified'];results={'etag':tag,'last_modified':modified}
 cases={
 'matching_tag':({'If-None-Match':tag},304),
 'weak_comparison':({'If-None-Match':'W/'+tag},304),
 'matching_date':({'If-Modified-Since':modified},304),
 'tag_takes_precedence':({'If-None-Match':'"different"','If-Modified-Since':modified},200),
 'weak_if_match_rejected':({'If-Match':'W/'+tag},412),
 }
 for name,(conditions,expected) in cases.items():
 status,_,body=request('/asset.txt',headers=conditions);assert status==expected,(name,status)
 if status==304:assert body==b''
 results[name]=status
 docker('exec',proxy,'sh','-c','printf BBBB > /srv/asset.txt');timestamp(1577836800)
 status,current,body=request('/asset.txt');assert status==200 and body==b'BBBB' and current['etag']==tag
 status,_,body=request('/asset.txt',headers={'If-None-Match':tag});assert status==304 and body==b''
 results['changed_bytes_preserved_metadata']=status
 timestamp(1577836802)
 status,current,body=request('/asset.txt',headers={'If-None-Match':tag})
 assert status==200 and body==b'BBBB' and current['etag']!=tag and current['last-modified']!=modified
 results['changed_metadata']={'status':status,'etag':current['etag']}
 status,current,_=request('/noetag.txt');assert status==200 and 'etag' not in current
 print(json.dumps(results,sort_keys=True))

最初文件内容是 AAAA，修改时间固定为 2020-01-01，产生 ETag "5e0be100-4"。GET 在 If-None-Match 中携带这个标签时，得到正文为空的 304。把请求标签加上 W/ 仍返回 304，因为该条件采用弱比较。在本次配置中，携带相等 If-Modified-Since 日期，也会得到 304。这些结果展示标签与日期两条验证路径。

如果同时发送不匹配的 If-None-Match 和匹配日期，则返回 200。这组结果符合 RFC 9110，但不能证明所有条件组合都遵循其优先级。固定版本过滤器先检查日期：若日期被判定为已修改，可能在检查匹配标签前返回 200。这一相反组合来自源码分析，并不是本实验已经执行的用例。单独的 If-Match 检查会拒绝弱请求标签并返回 412。这里实际执行的是 GET 前提条件检查，并没有执行写入业务流程，因此不能把结果扩展为完整并发写保护已经验证。

随后脚本把 AAAA 改成 BBBB，并恢复原修改时间。无条件 GET 证明正文已经变化，而标签仍完全相同。再次发送旧标签，又得到 304。这是有意构造的反例：即使 nginx 正确执行自己的标签生成算法，部署时保留元数据也可能破坏期望的表示身份契约。检查正文变化和标签变化必须配对进行，不能只看一个成功状态码。

把文件时间推进两秒后，生成的标签和 Last-Modified 都变化了。携带旧标签的请求随后得到 200 和 BBBB。最后一个对照在另一资源上关闭 etag，确认不再生成 ETag 响应头。关闭标签只是移除这一验证器，不会自动得到更强的替代，也不会自动关闭所有缓存。要采取哪种验证策略，仍需与实际发布方式一起设计。

让部署保持验证器契约

如果需要不同版本的字节分别拥有稳定地址，可以用内容导出的文件名在 URL 层区分版本。对于必须保留的稳定 URL，应确保表示字节变化时部署元数据也随之变化，或者由服务应用明确提供合适的内容派生验证器。审阅时既要考虑快速发生的同长度更新，也要检查复制新内容时保留时间戳的工具，避免只覆盖普通手工修改路径。

Last-Modified 同样需要谨慎理解。它是精度有限的时间戳，不是密码学身份。不能把任何日期都直接视为续传所需的强验证器；协议规定的条件和服务器真实更新行为都有关，尤其是一个有效时间精度窗口内可能出现多个版本时。实验推进两秒是为了明确改变输入，并不是宣称等待两秒能解决所有发布一致性问题。

最后，应检查经过中间层和内容编码后真正交付的表示。在要求强比较的场景，一种表示的验证器不能错误地标识另一串不同字节。把缓存寿命、条件验证、隐私和字节完整性分别作为明确决策，并在部署检查中同时验证未变化和已变化两种情况，才能发现这类只在更新时出现的问题。

来源

RFC 9110 HTTP Semantics，强弱验证器、条件优先级及 304、412 响应，已核验 2026-09-12。
RFC 9111 HTTP Caching，新鲜度、已存响应与成功验证，已核验 2026-09-12。
nginx 1.28.0 core source，根据修改时间与内容长度生成静态 ETag 的实现，已核验 2026-09-12。
nginx HTTP core module，etag 与 if_modified_since 配置，已核验 2026-09-12。
nginx 1.28.0 条件过滤器，日期检查顺序与强弱标签比较，已核验 2026-10-18。

gzip、HTTP/2 与 Brotli 需要分别验证

Fri, 28 Jan 2028 00:00:00 +0000

HTTP/2 改变 HTTP 传输分帧和多路复用方式；gzip 与 Brotli 编码的是表示数据。启用 HTTP/2 不会自动压缩响应正文，启用 gzip 也不能证明客户端协商出了 HTTP/2。HTTP/2 的头部压缩又是另一种机制。可靠检查应分别记录协商协议、响应 Content-Encoding、传输正文字节数，以及实际解码后得到的内容，不能用其中一项代替其他结果。

坏掉的样子

发送 Accept-Encoding: gzip, br，然后把结果保存成 .br，并不能证明使用了 Brotli。服务器可能选择 gzip，也可能发送仍被请求接受的原始表示。真实编码由响应头说明。根据请求列表或输出文件名猜测，会导致使用错误解码器，也可能让报告声称获得了实际上根本没有发生的压缩结果。文件名只是本地命名，不是协议证据。

Brotli 支持还属于部署能力，并不是安装 nginx 后自然具备的功能。Brotli 过滤和预压缩文件处理由独立模块提供，需要针对实际二进制与配置确认可用性、构建兼容性。添加不受支持的指令可能让配置验证失败，而客户端声明接受 Brotli 不会替服务器安装功能。检查模块时，应以当前程序行为为准，不能从另一台机器的配置推断。

客户端自动解码会制造另一种测量陷阱。curl --compressed 收到较小编码正文后，可以保存成较大的解码文件。把这个文件大小与原始压缩输出比较，实际比较的是不同对象。反过来，只使用 --http2 却不检查协商结果，也可能把允许的协议回落误当成 HTTP/2 已经成功验证。命令选项表达请求意图，结果字段才说明本次发生了什么。

分别核对实际协议、编码与解码一致性。字节数来自历史文章报告，当前集成仍待验证。

快速验证

下文结果归属于历史文章报告，本轮没有重跑；保留的验证文件中未找到原始集成运行日志。运行需备好本地固定镜像并启用 Python 断言；清理仅尽力执行，不能据此保证所有资源已删除。

将脚本保存为 check-h2-coding.py，准备 Docker、Python、OpenSSL 和支持 HTTP/2 的 curl 后运行。记录客户端为带 nghttp2 的 curl 8.7.1，服务器为 Linux arm64 上的 nginx 1.28.0。脚本生成短期本地证书，并通过 --cacert 显式信任该证书，只发布宿主回环端口，不需要连接真实公网服务：

from contextlib import contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import http.client,json,socket,subprocess,time,uuid

NGINX='nginx@sha256:552e7481ca93ffccd046aa658dbbed22caefbc09c66fa7cd247cbb90b8a5c609'
PYTHON='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def wait(predicate):
 deadline=time.monotonic()+15
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except OSError:pass
 time.sleep(.1)
 raise AssertionError('fixture did not become ready')

@contextmanager
def lab(configuration,files=None,backend=None):
 name='xbcatm-nginx-'+uuid.uuid4().hex[:10];tags=[name+':proxy',name+':backend'];containers=[name+'-proxy',name+'-backend']
 try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'files').mkdir();(root/'nginx.conf').write_text(configuration)
 for path,content in (files or {}).items():
 target=root/'files'/path;target.parent.mkdir(parents=True,exist_ok=True)
 target.write_bytes(content if isinstance(content,bytes) else content.encode())
 docker('network','create',name)
 if backend is not None:
 (root/'backend.py').write_text(backend)
 (root/'backend.Dockerfile').write_text(f'FROM {PYTHON}\nCOPY backend.py /backend.py\nCMD ["python", "/backend.py"]\n')
 docker('build','--network','none','-f',str(root/'backend.Dockerfile'),'-t',tags[1],str(root))
 docker('run','-d','--name',containers[1],'--network',name,'--network-alias','backend',tags[1])
 wait(lambda:docker('exec',containers[1],'python','-c','import socket;s=socket.create_connection(("127.0.0.1",8081),timeout=.5);s.close()',check=False).returncode==0)
 (root/'Dockerfile').write_text(f'FROM {NGINX}\nCOPY nginx.conf /etc/nginx/nginx.conf\nCOPY files /srv\n')
 docker('build','--network','none','-t',tags[0],str(root))
 docker('run','--rm','--network',name,tags[0],'nginx','-t')
 docker('run','-d','--name',containers[0],'--network',name,'-p','127.0.0.1::8080',tags[0])
 details=json.loads(docker('inspect',containers[0]).stdout)[0]
 binding=details['NetworkSettings']['Ports']['8080/tcp'][0];assert binding['HostIp']=='127.0.0.1';port=int(binding['HostPort'])
 def ready():
 connection=socket.create_connection(('127.0.0.1',port),timeout=.5);connection.close();return True
 wait(ready)
 def request(path,method='GET',headers=None,body=None):
 connection=http.client.HTTPConnection('127.0.0.1',port,timeout=5)
 try:
 connection.request(method,path,body=body,headers=headers or {})
 response=connection.getresponse();return response.status,{k.lower():v for k,v in response.getheaders()},response.read()
 finally:connection.close()
 request.port=port
 yield containers[0],request
 finally:
 docker('rm','-f',*containers,check=False);docker('image','rm',*tags,check=False);docker('network','rm',name,check=False)

def config(locations,extra=''):
 return 'worker_processes 1;\nerror_log /tmp/error.log notice;\nevents {}\nhttp {\naccess_log off;\n'+extra+'\nserver { listen 8080; root /srv;\n'+locations+'\n}\n}\n'
import gzip,hashlib
payload=(b'{"message":"'+b'HTTP content coding and transport are separate. '*1000+b'"}\n')
with TemporaryDirectory(prefix='xbcatm-local-tls-') as directory:
 root=Path(directory);cert=root/'cert.pem';key=root/'key.pem'
 result=subprocess.run(['openssl','req','-x509','-newkey','ec','-pkeyopt','ec_paramgen_curve:prime256v1',
 '-nodes','-keyout',str(key),'-out',str(cert),'-days','1','-subj','/CN=localhost',
 '-addext','subjectAltName=DNS:localhost,IP:127.0.0.1'],capture_output=True,text=True)
 assert result.returncode==0,result.stderr
 configuration=config('location = /app.json {} location / { return 404; }',
 'gzip on; gzip_types application/json; gzip_vary on; types { application/json json; }')
 configuration=configuration.replace('listen 8080;', 'listen 8080 ssl; http2 on; ssl_certificate /srv/cert.pem; ssl_certificate_key /srv/key.pem;')
 files={'cert.pem':cert.read_bytes(),'key.pem':key.read_bytes(),'app.json':payload,
 'brotli.conf':'events {} http { brotli on; server { listen 8080; } }'}
 with lab(configuration,files) as (proxy,request):
 probe=docker('exec',proxy,'nginx','-t','-c','/srv/brotli.conf',check=False)
 assert probe.returncode!=0 and 'unknown directive "brotli"' in probe.stderr
 results={'brotli_directive_supported':False}
 for name,version,accept,decode in [
 ('h2_gzip','2','gzip, br',False),('h1_gzip','1.1','gzip',False),
 ('h2_br_only','2','br',False),('h2_identity','2','identity',False),
 ('h2_decoded','2','gzip',True)]:
 output=root/(name+'.body');header=root/(name+'.headers')
 args=['curl','--silent','--show-error','--fail','--noproxy','*','--cacert',str(cert),
 '--http2' if version=='2' else '--http1.1','--header','Accept-Encoding: '+accept,
 '--output',str(output),'--dump-header',str(header),'--write-out','%{http_version}\n%{size_download}\n',
 f'https://127.0.0.1:{request.port}/app.json']
 if decode:args.insert(1,'--compressed')
 run=subprocess.run(args,capture_output=True,text=True,timeout=15);assert run.returncode==0,run.stderr
 actual,download=run.stdout.strip().splitlines();assert actual==version,(name,run.stdout)
 headers={k.lower():v.strip() for line in header.read_text().splitlines() if ':' in line for k,v in [line.split(':',1)]}
 body=output.read_bytes();encoded='gzip' in accept
 assert headers.get('content-encoding')==('gzip' if encoded else None)
 assert (gzip.decompress(body) if encoded and not decode else body)==payload
 assert headers['vary']=='Accept-Encoding'
 results[name]={'protocol':actual,'content_encoding':headers.get('content-encoding','identity'),
 'download_body_bytes':int(download),'saved_file_bytes':len(body)}
 assert results['h2_gzip']['download_body_bytes']<len(payload)
 assert results['h2_decoded']['saved_file_bytes']==len(payload)
 rejected={}
 for path in ['/key.pem','/cert.pem','/brotli.conf']:
 run=subprocess.run(['curl','--silent','--show-error','--noproxy','*','--cacert',str(cert),
 '--http2','--output',str(root/'rejected.body'),'--write-out','%{http_code}',
 f'https://127.0.0.1:{request.port}'+path],capture_output=True,text=True,timeout=15)
 assert run.returncode==0 and run.stdout=='404',(path,run.stdout,run.stderr)
 rejected[path]=404
 results['non_asset_statuses']=rejected
 results['original_sha256']=hashlib.sha256(payload).hexdigest()
 print(json.dumps(results,sort_keys=True))

证书的主题备用名称包含回环 IP，因此本地 HTTPS 请求可以同时验证信任和请求身份。实验没有关闭证书校验。路由只允许提供 JSON 资源，请求密钥、证书和探测配置都必须返回 404。生成的测试密钥会复制进镜像层，删除标签后仍可能留在 Docker 构建缓存中；绝不能替换成生产密钥。脚本尝试删除容器、镜像标签、网络和临时文件，但不验证缓存清除。这些设置用于建立可验证的本地 TLS 条件，不代表替生产域名完成了证书部署。

合成 JSON 表示共有 48,015 字节。在实际协商出的 HTTP/2 上，请求同时声明 gzip 和 Brotli，收到 Content-Encoding: gzip，记录到正文为 381 字节。解码能逐字节还原原内容。显式使用 HTTP/1.1 时也得到 gzip。两组结果说明正文编码可以跨这两种已测传输使用，而不是只有选中 HTTP/2 才会发生压缩。

HTTP/2 的 identity 请求得到 48,015 字节未编码正文。只声明 br 的请求在此配置中也得到 identity，因为该请求头仍接受原始表示。实验另外用包含 brotli on 的配置执行检查，并要求 nginx 以未知指令拒绝它。这两个观察共同说明：本次被测配置没有交付 Brotli，不能把客户端声明和服务器实际能力混为一谈。

使用 --compressed 时，curl 仍报告下载正文为 381 字节，但保存文件包含原来的 48,015 字节解码内容。脚本同时核对两种计量和实际内容。下载正文数字不包含其他传输开销，它不是完整抓包，也不是该连接所有 TLS 与 HTTP/2 分帧字节的总量。比较压缩收益时，应让计量边界保持一致。

先确认能力，再比较性能

示例在 TLS 监听上显式开启 HTTP/2，并检查 curl 返回的真实协议值。它在本地提供静态内容，因此不对上游应用采用什么传输协议作结论。反向代理可以与客户端协商一种协议，又用另一种协议连接后端；如果这个区别影响容量或行为，应分别检查两条连接，不能把入口协议直接推广到整个调用链。

部署 Brotli 时，先建立实际模块或预压缩文件交付路径，再要求得到真实 br 响应并成功 Brotli 解码，之后才讨论节省量。这里提供的是负向能力检查，不是 Brotli 性能基准。安装模块或重新构建 nginx 属于另一项配置变更，需要针对兼容性和实际交付重新验证，而不是把未经执行的安装步骤写成已有结果。

最后，要用有代表性的内容和一致计量比较效果。高度重复的测试正文证明编码与解码正确，不提供通用压缩比，也不证明页面一定加速多少。通过 Vary 表达的缓存选择、编码正文字节、解码正确性、CPU 使用和客户端延迟，应作为不同观察记录。协议版本或编码器名称本身，都不足以证明页面变快。

来源

nginx gzip module，响应内容编码及 Vary 配置，已核验 2026-10-15。
nginx HTTP/2 module，HTTP/2 启用与 TLS ALPN 要求，已核验 2026-10-15。
Google ngx_brotli module README，独立 Brotli filter、static 模块及构建要求，已核验 2026-10-15。
RFC 9110 HTTP Semantics，内容编码协商及 identity 的可接受性，已核验 2026-10-15。
Docker build garbage collection，构建缓存生命周期独立于镜像标签清理，已核验 2026-10-18。

先决定让 nginx 跳转客户端，还是在内部重写

Fri, 21 Jan 2028 00:00:00 +0000

nginx 跳转与内部重写改变请求流程的不同部分。跳转返回状态和 Location，由客户端决定是否发起新请求；内部重写则在处理现有请求时改变 nginx 当前 URI。两者的选择决定客户端是否看到新地址、location 是否重新搜索，以及最终处理器收到怎样的路径和查询。不能因为都能让某个 URL 得到内容，就把它们当成同一种操作。

坏掉的样子

本来需要内部映射，却改成跳转，会增加客户端往返并暴露新 URL；本来需要公开永久迁移，却只做内部重写，客户端仍会继续使用旧地址。return 和 rewrite 也不能被当成总是默认相同跳转行为的通用缩写。明确状态码与重写标志，才能让预期转换可审阅，避免一行看似简单的配置隐藏行为差异。

状态选择影响方法语义和缓存。307、308 在自动跳转时保留请求方法，301、302 则允许历史上的 POST 改为 GET。永久不意味着每个客户端立刻更新所有已保存链接，临时也不意味着响应绝对不能缓存。缓存指令、请求上下文和客户端行为仍然重要，不能用状态名称替代明确的复用策略。

内部重写还可能选择错误处理器，或反复匹配自己。last 会为改变后的 URI 开始新 location 搜索；break 结束当前重写序列后，继续在现有 location 处理。查询参数可以按替换语法追加或丢弃。把这些区别视为可以互换，可能导致读取错误文件、重复参数，或进入返回 HTTP 500 的循环。

客户端新请求，或内部转换。依据原文与明确限制静态绘制；未为本图重跑原文夹具。

快速验证

下文集成实验的结果保留自历史运行记录；本次修订没有重新执行该实验，不能将这些记录当成本次环境的新实测。

使用宿主 Python、Docker 和固定 nginx 镜像运行脚本。实测为 Linux arm64 上的 nginx 1.28.0、Docker 29.3.1。它构建并检查可丢弃配置，只发布回环端口，不自动跟随跳转地验证真实响应，最后清理自身资源。一个小型静态文件让 break 所用处理器可以与目标 location 清楚区分：

from contextlib import contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import http.client,json,socket,subprocess,time,uuid

NGINX='nginx@sha256:552e7481ca93ffccd046aa658dbbed22caefbc09c66fa7cd247cbb90b8a5c609'
PYTHON='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def wait(predicate):
 deadline=time.monotonic()+15
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except OSError:pass
 time.sleep(.1)
 raise AssertionError('fixture did not become ready')

@contextmanager
def lab(configuration,files=None,backend=None):
 name='xbcatm-nginx-'+uuid.uuid4().hex[:10];tags=[name+':proxy',name+':backend'];containers=[name+'-proxy',name+'-backend']
 try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'files').mkdir();(root/'nginx.conf').write_text(configuration)
 for path,content in (files or {}).items():
 target=root/'files'/path;target.parent.mkdir(parents=True,exist_ok=True);target.write_text(content)
 docker('network','create',name)
 if backend is not None:
 (root/'backend.py').write_text(backend)
 (root/'backend.Dockerfile').write_text(f'FROM {PYTHON}\nCOPY backend.py /backend.py\nCMD ["python", "/backend.py"]\n')
 docker('build','--network','none','-f',str(root/'backend.Dockerfile'),'-t',tags[1],str(root))
 docker('run','-d','--name',containers[1],'--network',name,'--network-alias','backend',tags[1])
 wait(lambda:docker('exec',containers[1],'python','-c','import socket;s=socket.create_connection(("127.0.0.1",8081),timeout=.5);s.close()',check=False).returncode==0)
 (root/'Dockerfile').write_text(f'FROM {NGINX}\nCOPY nginx.conf /etc/nginx/nginx.conf\nCOPY files /srv\n')
 docker('build','--network','none','-t',tags[0],str(root))
 docker('run','--rm','--network',name,tags[0],'nginx','-t')
 docker('run','-d','--name',containers[0],'--network',name,'-p','127.0.0.1::8080',tags[0])
 details=json.loads(docker('inspect',containers[0]).stdout)[0]
 binding=details['NetworkSettings']['Ports']['8080/tcp'][0];assert binding['HostIp']=='127.0.0.1';port=int(binding['HostPort'])
 def ready():
 connection=socket.create_connection(('127.0.0.1',port),timeout=.5);connection.close();return True
 wait(ready)
 def request(path,method='GET',headers=None,body=None):
 connection=http.client.HTTPConnection('127.0.0.1',port,timeout=5)
 try:
 connection.request(method,path,body=body,headers=headers or {})
 response=connection.getresponse();return response.status,{k.lower():v for k,v in response.getheaders()},response.read()
 finally:connection.close()
 yield containers[0],request
 finally:
 docker('rm','-f',*containers,check=False);docker('image','rm',*tags,check=False);docker('network','rm',name,check=False)

def config(locations,extra=''):
 return 'worker_processes 1;\nerror_log /tmp/error.log notice;\nevents {}\nhttp {\naccess_log off;\n'+extra+'\nserver { listen 8080; root /srv;\n'+locations+'\n}\n}\n'

locations=r'''
location = /old { return 308 /destination$is_args$args; }
location = /destination { return 200 "$request_method|$uri|$args"; }
location /last/ { rewrite ^/last/(.*)$ /target/$1 last; }
location /break/ { rewrite ^/break/(.*)$ /target/$1 break; add_header X-Route break always; }
location /target/ { add_header X-Route target always; return 200 "$uri|$args"; }
location /append/ { rewrite ^/append/(.*)$ /target/$1?new=1 last; }
location /discard/ { rewrite ^/discard/(.*)$ /target/$1? last; }
location /loop/ { rewrite ^ /loop/again last; }
'''
with lab(config(locations,'absolute_redirect off;'),{'target/item':'static-file'}) as (container,request):
 status,headers,body=request('/old?x=1',method='POST',body='public-body')
 assert status==308 and headers['location']=='/destination?x=1'
 status,headers,body=request(headers['location'],method='POST',body='public-body');assert status==200 and body==b'POST|/destination|x=1'
 status,headers,body=request('/last/item?x=1');assert status==200 and headers['x-route']=='target' and body==b'/target/item|x=1'
 status,headers,body=request('/break/item?x=1');assert status==200 and headers['x-route']=='break' and body==b'static-file'
 status,headers,body=request('/append/item?old=2');assert status==200 and body==b'/target/item|new=1&old=2'
 status,headers,body=request('/discard/item?old=2');assert status==200 and body==b'/target/item|'
 assert request('/loop/start')[0]==500
 assert 'rewrite or internal redirection cycle' in docker('exec',container,'cat','/tmp/error.log').stdout
 print('return 308 creates a client-visible redirect; the explicit follow-up retains POST and the query')
 print('last restarts location selection; break keeps the location while changing the URI used by its static handler')
 print('rewrite appends old query arguments unless discarded explicitly; an internal rewrite cycle is stopped with HTTP 500')

向 /old?x=1 发送 POST，得到 308 和 Location: /destination?x=1。实验关闭绝对跳转生成，让本地目标保持相对形式，不依赖自动分配的宿主端口。任何后续请求之前，都会先检查原响应，从而明确 nginx 实际告诉客户端什么，不让自动跟随把第一跳隐藏起来。

随后，脚本显式向该 Location 再发送一次 POST，得到 POST|/destination|x=1。这验证按预期方法跟随时的目标和查询，但不声称覆盖所有浏览器的自动跳转或缓存行为。测试客户端有意控制第二次请求，而不是默默执行它。因此，实验结果应与 HTTP 状态契约结合理解，不能扩展成未经执行的客户端兼容性结论。

/last/item?x=1 被重写为 /target/item，并重新选择 location。目标块返回诊断 URI，X-Route 为 target。相比之下，/break/item?x=1 改变 URI 后仍留在原 location，其静态处理器读取 /srv/target/item，响应标记为 break。相同目标路径因此可以经过不同配置处理，不能只看重写后的字符串。

这些结果说明 break 不会停止全部请求处理，它只停止当前重写序列，内容处理仍继续。同样，last 不是外部跳转：客户端直接收到最终 200，不会先获得一条 Location 跳到内部目标。状态、响应头与正文共同证明转换类型，避免仅凭规则名字猜测。

/append/item?old=2 的替换包含 new=1，它与原参数组合成 new=1&old=2。丢弃示例在替换末尾使用问号，最终没有参数。两种情况都断言实际结果，避免跳转或重写测试漏掉重复、泄漏或意外删除的查询数据。路径正确不代表参数同样正确，两者应分别比较。

循环路径不断重写回自身匹配家族。nginx 最终以 HTTP 500 停止循环，并在错误日志记录内部跳转循环诊断。因此，语法检查成功不证明某个请求不会循环；只有实际执行相关匹配路径，才能验证转换按预期终止。错误日志还为区分后端故障与本地规则循环提供了直接证据。

测试客户端真正收到的转换

简单公开迁移可以使用带明确状态的 return，需要模式匹配时再采用对应 rewrite。目标路径和查询处理应清楚表达。避免让不可信输入任意决定跳转地址；绝对目标依赖传入主机信息时，还要验证规范主机策略。配置不应因为修复一个路径，顺便允许请求者选择完全无关的目标。

公开迁移在选择缓存策略前，应验证状态、Location、方法预期和最终目标。需要禁止复用时，临时状态不能替代明确缓存控制。内部映射则应检查最终 location、文件或上游路径、参数及错误情况。两类验证关注不同结果，不应把其中一种成功直接代替另一种。

回归应包含近似路径和已经规范化的目标。规则第一次工作，不代表不会再次跳转自己的目标，或与后续 location 冲突。保留原始响应和最终结果两侧证据，才能在部署后解释路由改变到底发生在哪一步，而不是只看到页面最终能打开就结束检查。

来源

nginx rewrite module，return 跳转、last 与 break、查询处理及重写次数限制，已核验 2026-10-15。
RFC 9110 HTTP semantics，跳转状态含义与方法保留要求，已核验 2026-10-15。
RFC 9111 HTTP caching，响应语义及缓存控制共同决定的缓存行为，已核验 2026-10-15。

Cache-Control 是缓存与源站之间的约定

Mon, 20 Dec 2027 00:00:00 +0000

缓存策略需要行为测试，而不只是检查头部是否存在。两个响应即使都带 max-age，也可能因为其中一个要求验证、另一个禁止存储而表现不同。请求本身同样影响结果：浏览器可以绕过已有副本，却不修改源站的响应策略，也不删除更早保存的缓存条目。要知道用户真正拿到什么，必须观察完整的重复请求过程。

Fetch no-store 取得版本二，原有缓存版本一仍保留；reload 取得并存入版本三。响应 Cache-Control 策略与 Fetch 缓存模式应分开。仅为来源示意；本任务未执行示例。

双方都要读同一份约定

Cache-Control 指令具有方向性。请求指令不会自动复制到响应里，RFC 9111 还明确将请求指令描述为建议性的要求；响应指令则约束遵守协议的缓存。中间层即使自己不实现缓存，也必须在转发中保留相应缓存指令。部署配置可能另有覆盖规则，但“代理按自己的配置做了”不等于已经证明源站声明的策略得到执行。

应拆开三个问题：这条响应能否存储，当前年龄是否仍在适用的新鲜度寿命内，这次请求是否允许不经验证直接复用。这里的 no-store 禁止 HTTP 缓存存储；不带字段名限定的 no-cache 允许存储，但复用前必须成功验证。示例不包含能够在特定条件下覆盖 no-store 的 must-understand 组合，不能据此推导所有指令组合的行为。max-age 设定新鲜度，must-revalidate 则禁止响应过期后未经验证就复用。响应仍然新鲜时，must-revalidate 本身并不要求每次回源，不能把它误解成 no-cache。

不带字段名限定的 private 将存储限制到单用户缓存，public 在其他条件允许时明确授予缓存许可，并不是每一条可缓存响应都必须写 public。s-maxage 覆盖共享缓存的新鲜度，并要求过期之后先验证再复用；它不适用于浏览器私有缓存。Vary 则提供请求匹配维度。这些机制都不会识别应用当前登录的是哪个账户，也不会因为有效期很短，就自动让个人数据变得适合共享。

坏掉的样子

测试时每次添加新的查询参数，会改变缓存键，可能完全掩盖原本的复用行为。在开发者工具中禁用缓存，也可能造成相同误判；某些自动化请求拦截机制同样会禁用 HTTP 缓存。有效测试应在一个隔离上下文中重复访问完全相同的网址，一边统计源站实际收到的请求，一边断言返回正文，而不是仅凭页面看起来没变化就判断命中。

Fetch 的 cache 选项属于浏览器接口，不是响应头。它的 no-store 模式跳过缓存查找，也不把新响应写回 HTTP 缓存；reload 跳过查找，但可以更新缓存。两者都不等于抹除全部旧副本。源站修改响应头，也不能迫使尚未过期的条目立刻回源。浏览器历史恢复、Service Worker 自行保存的内容又是其他机制，不属于下面实验的覆盖范围。

no-cache 也不保证获得 304。只有存在合适的验证器，并且所选表示仍然有效，才有机会节省正文传输。没有 ETag 或 Last-Modified 时，每次访问可能仍返回完整的 200 响应。因此要同时测量回源次数和传输正文，不能看到“每次都请求了源站”就认为重验证一定已经发挥性能收益。

快速验证

作者记录过一次 macOS 上使用 Node 26.0.0、Playwright 1.63.0 及其配套 Chromium 153.0.8010.12 无头浏览器的验证；本轮审阅没有重跑这项浏览器实验。将依赖装入临时目录；Linux 还需具备 Playwright 文档要求的浏览器系统依赖。下载需要联网。使用 NODE_PATH="$cache_browser_lab/node_modules" PLAYWRIGHT_BROWSERS_PATH="$cache_browser_lab/browsers" node 执行 JavaScript，测试请求只访问自动分配的回环端口，不使用现有浏览器配置。

cache_browser_lab=$(mktemp -d)
npm install --prefix "$cache_browser_lab" --ignore-scripts --no-audit --no-fund --package-lock=false playwright@1.63.0
PLAYWRIGHT_BROWSERS_PATH="$cache_browser_lab/browsers" node "$cache_browser_lab/node_modules/playwright/cli.js" install chromium --only-shell --no-remove

const assert = require("node:assert/strict");
const http = require("node:http");
const { once } = require("node:events");
const { chromium } = require("playwright");

const policies = new Map([
 ["/fresh", "max-age=3600"],
 ["/must", "max-age=3600, must-revalidate"],
 ["/validate", "no-cache, max-age=3600"],
 ["/discard", "no-store, max-age=3600"],
]);
const hits = new Map();
const server = http.createServer((request, response) => {
 const route = new URL(request.url, "http://127.0.0.1").pathname;
 if (route === "/") {
 response.writeHead(200, { "Content-Type": "text/html", "Cache-Control": "no-store" });
 response.end("<!doctype html><title>Cache experiment</title>");
 } else if (policies.has(route)) {
 const count = (hits.get(route) || 0) + 1;
 hits.set(route, count);
 response.writeHead(200, {
 "Content-Type": "text/plain", "Cache-Control": policies.get(route),
 });
 response.end(`${route}:${count}`);
 } else {
 response.writeHead(404, { "Cache-Control": "no-store" });
 response.end();
 }
});

async function main() {
 server.listen(0, "127.0.0.1");
 await once(server, "listening");
 let browser;
 try {
 browser = await chromium.launch();
 console.log("Chromium", browser.version());
 const context = await browser.newContext({ serviceWorkers: "block" });
 try {
 const page = await context.newPage();
 await page.goto(`http://127.0.0.1:${server.address().port}/`);
 const read = (route, cache = "default") => page.evaluate(async ({ route, cache }) => {
 const response = await fetch(route, { cache });
 if (!response.ok) throw new Error(`HTTP ${response.status}`);
 return response.text();
 }, { route, cache });
 for (const [route, expectedHits] of [
 ["/fresh", 1], ["/must", 1], ["/validate", 2], ["/discard", 2],
 ]) {
 const first = await read(route);
 const second = await read(route);
 assert.equal(first, `${route}:1`);
 assert.equal(second, `${route}:${expectedHits}`);
 assert.equal(hits.get(route), expectedHits);
 console.log(route, "origin requests:", hits.get(route));
 }
 assert.equal(await read("/fresh", "no-store"), "/fresh:2");
 assert.equal(await read("/fresh"), "/fresh:1");
 assert.equal(hits.get("/fresh"), 2);
 assert.equal(await read("/fresh", "reload"), "/fresh:3");
 assert.equal(await read("/fresh"), "/fresh:3");
 assert.equal(hits.get("/fresh"), 3);
 console.log("no-store bypass retained version 1; reload stored version 3");
 } finally {
 await context.close();
 }
 } finally {
 if (browser) await browser.close();
 await new Promise((resolve, reject) => server.close(error => error ? reject(error) : resolve()));
 }
}

main().catch(error => { console.error(error); process.exitCode = 1; });

最初四条路由的回源次数依次为一、一、二、二。两个新鲜策略都复用第一次拿到的正文；no-cache 与 no-store 即使搭配很长的 max-age，也会再次访问源站。这里有意不提供验证器，所以回源返回的是完整正文。仅凭这些次数，不能区分 no-cache 和 no-store 的存储资格，实验也没有做出这种推断。

后续 no-store 模式取得版本二，但紧接着的普通请求仍返回先前缓存的版本一。reload 模式取得并保存版本三，下一次普通请求便复用版本三。源站计数器证明这些确实是缓存决策，不是两次响应字符串碰巧相同。最后关闭服务器和隔离浏览器上下文，不改变日常使用的浏览器状态。

这些观察只覆盖这个 Chromium HTTP 缓存和列出的请求，没有验证共享 CDN、重启后的持久化、陈旧响应或账户隔离。它们需要各自的验收。局部实验的价值在于明确客户端实际执行了什么，而不是把一次可复现的本地结果延伸成整条生产交付链都正确的结论。

来源

RFC 9111：Cache-Control，指令方向性及存储、复用要求，已核验 2026-09-07。
MDN：Request.cache，default、no-store 和 reload 行为，已核验 2026-09-07。
Playwright 浏览器上下文，隔离且非持久化的上下文，已核验 2026-09-07。
Playwright 浏览器安装，配套无头浏览器与系统依赖，已核验 2026-09-07。
Fetch 标准：缓存模式，no-store 绕过缓存与 reload 更新缓存的区别，已核验 2026-10-15。

CONNECT 方法打开一条裸隧道

Mon, 13 Dec 2027 00:00:00 +0000

CONNECT 请求代理建立隧道，并不让代理从数据路径上消失。准入成功之后，代理仍然向两个方向转发字节，并管理套接字、缓冲区和故障处理。CONNECT 本身不提供加密；HTTPS 是在这条隧道内部另行建立并验证 TLS 会话，不能把两个阶段的成功混为一谈。

在正确的边界切换语义

HTTP/1.1 的 CONNECT 目标是 server.example:443 这样的主机与端口组合，而不是普通路径或完整 HTTPS URL。端口必须明确给出。成功的 2xx 响应在响应头结束后立即切换到隧道模式；非成功响应则表示隧道尚未建立，此时不能直接开始把后续内容当作目标服务的数据。

成功的 CONNECT 响应不能携带 Content-Length 或 Transfer-Encoding。随后出现的字节属于隧道，而不是一份用长度界定的 HTTP 响应正文。自己实现中继时，这一点尤其重要：HTTP 解析器已经缓冲的字节也可能属于隧道，不能因为切换到原始套接字，就把此前预读的数据丢掉。

客户端随后可以穿过中继，与目标协商 TLS。代理返回 200 只说明允许并建立了隧道，不负责证明目标证书有效，也不证明应用请求成功。客户端仍须检查信任链、主机名与应用响应。TLS 拦截属于另一种部署方式，需要客户端信任会终止 TLS 的中间实体，不能把它与普通盲转发混为同一种安全模型。

看不见正文，仍然占用资源

盲中继不必解释加密的应用内容，但仍能观察目标地址、字节量、时序和关闭行为。它可以落实连接预算、超时、流量限制，以及撤销准入之后的断开操作。无法读取 TLS 内部的 HTTP 消息，不等于失去所有运营控制，更不等于不再承担带宽和描述符成本。

真正的正向代理应验证调用方身份，并限制目的地。任意主机和端口访问，可能暴露内部服务，或被用于其他协议的滥用。按主机名放行时，还必须考虑地址解析策略：通过名称检查，并不自动证明最终拨号的 IP 地址符合约束。本地实验只允许一个预先确定的环回地址与端口，因此没有引入任意目标的解析和转发能力。

坏掉的样子

代理可能在上游尚未连通时就返回 200，可能丢弃解析器缓冲的字节，也可能在待转发数据尚未送出时，过早关闭另一个方向。这些错误看起来可能像证书配置正确却仍然失败的 TLS 握手。排障时，应分别记录准入失败、隧道传输失败、TLS 身份验证失败和源站 HTTP 失败。

Go 的 HTTP/1.1 连接一旦被 Hijack，生命周期就交给处理函数负责，普通 HTTP 服务端不会再管理它。请求上下文也不能代替隧道清理，需要显式管理两个复制方向和截止时间。普通服务端停机不会自动关闭已经接管的连接，生产停机需要记录这些连接，并显式排空或关闭，避免遗漏长连接。固定的绝对期限限制的是连接总寿命，并不是每收到一批流量就自动续期的空闲超时；两者不能使用同一个解释。

CONNECT 准入双向中继，TLS 单独验证目标；代理仍负责套接字和清理。历史本地实验不是可部署的公共代理。

快速验证

保存为 connect_probe.go，使用 Go 1.23 或更新版本运行 go run connect_probe.go。实验建立环回 HTTP/1.1 代理和 TLS 1.3 源站，只允许源站的精确主机端口组合。客户端信任这台测试服务的证书，不关闭证书验证，也不修改系统信任库。

package main

import (
 "context"
 "crypto/tls"
 "crypto/x509"
 "errors"
 "fmt"
 "io"
 "log"
 "net"
 "net/http"
 "net/http/httptest"
 "net/url"
 "runtime"
 "sync/atomic"
 "time"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 var handled, admitted, denied, connectStatus atomic.Int64
 origin := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 check(r.TLS != nil && r.TLS.Version == tls.VersionTLS13, "origin requires TLS 1.3")
 fmt.Fprint(w, "through the tunnel")
 }))
 origin.Config.ErrorLog = log.New(io.Discard, "", 0) // Expected wrong-name handshake failure.
 origin.TLS = &tls.Config{MinVersion: tls.VersionTLS13, MaxVersion: tls.VersionTLS13}
 origin.StartTLS()
 defer origin.Close()
 target, err := url.Parse(origin.URL)
 must(err)
 relayed := make(chan [2]int64, 3)
 proxy := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 if r.Method != http.MethodConnect {
 http.Error(w, "CONNECT required", http.StatusMethodNotAllowed)
 return
 }
 if r.Host != target.Host || r.URL.Host != target.Host {
 denied.Add(1)
 http.Error(w, "target denied", http.StatusForbidden)
 return
 }
 upstream, err := net.DialTimeout("tcp", target.Host, time.Second)
 must(err)
 defer upstream.Close()
 downstream, buffered, err := w.(http.Hijacker).Hijack()
 must(err)
 defer downstream.Close()
 admitted.Add(1)
 deadline := time.Now().Add(3 * time.Second)
 must(upstream.SetDeadline(deadline))
 must(downstream.SetDeadline(deadline))
 _, err = buffered.WriteString("HTTP/1.1 200 Connection Established\r\n\r\n")
 must(err)
 must(buffered.Flush())
 upDone := make(chan int64, 1)
 go func() {
 count, _ := io.Copy(upstream, buffered) // Preserve already-buffered tunnel bytes.
 _ = upstream.(*net.TCPConn).CloseWrite()
 upDone <- count
 }()
 count, _ := io.Copy(downstream, upstream)
 _ = downstream.(*net.TCPConn).CloseWrite()
 relayed <- [2]int64{<-upDone, count}
 }))
 defer proxy.Close()
 proxyURL, err := url.Parse(proxy.URL)
 must(err)
 config := origin.Client().Transport.(*http.Transport).TLSClientConfig.Clone()
 check(!config.InsecureSkipVerify, "certificate verification must stay enabled")
 transport := &http.Transport{
 Proxy: http.ProxyURL(proxyURL), TLSClientConfig: config, DisableKeepAlives: true,
 OnProxyConnectResponse: func(_ context.Context, _ *url.URL, _ *http.Request, response *http.Response) error {
 connectStatus.Store(int64(response.StatusCode))
 if response.StatusCode == 200 {
 check(response.Header.Get("Content-Length") == "" && response.Header.Get("Transfer-Encoding") == "", "successful CONNECT must not frame a body")
 }
 return nil
 },
 }
 defer transport.CloseIdleConnections()
 get := func(tr *http.Transport, address string) (*http.Response, error) {
 return (&http.Client{Transport: tr, Timeout: 2 * time.Second}).Get(address)
 }
 success := func(label string) {
 response, err := get(transport, origin.URL)
 must(err)
 body, readError := io.ReadAll(response.Body)
 closeError := response.Body.Close()
 must(readError)
 must(closeError)
 check(response.StatusCode == 200 && string(body) == "through the tunnel", "wrong origin response")
 check(connectStatus.Load() == 200 && len(response.TLS.VerifiedChains) > 0, "CONNECT and verified TLS required")
 fmt.Println(label, "CONNECT=200; verified origin response")
 }
 success("allowed")
 response, err := get(transport, "https://denied.invalid:443/")
 check(err != nil && response == nil && connectStatus.Load() == 403, "proxy must reject the target")
 check(denied.Load() == 1 && admitted.Load() == 1 && handled.Load() == 1, "denial must not open an upstream tunnel")
 fmt.Println("denied CONNECT=403; no upstream admission")

 wrong := transport.Clone()
 wrong.TLSClientConfig = config.Clone()
 wrong.TLSClientConfig.ServerName = "wrong.invalid"
 defer wrong.CloseIdleConnections()
 response, err = get(wrong, origin.URL)
 var hostnameError x509.HostnameError
 check(response == nil && errors.As(err, &hostnameError) && connectStatus.Load() == 200, "client must verify the tunneled TLS identity")
 check(handled.Load() == 1, "wrong-name TLS must not reach the HTTP handler")
 fmt.Println("wrong name CONNECT=200; TLS rejected before origin HTTP")
 success("recovery")
 check(handled.Load() == 2 && admitted.Load() == 3, "wrong final origin/tunnel counts")
 for index := 0; index < 3; index++ {
 select {
 case counts := <-relayed:
 check(counts[0] > 0 && counts[1] > 0, "proxy must relay bytes in both directions")
 case <-time.After(4 * time.Second):
 panic("relay did not finish")
 }
 }
 fmt.Println("three completed relays; two successful origin HTTP requests")
 fmt.Println(runtime.Version())
}

第一次请求记录 CONNECT 200，并读到完整的源站正文。denied.invalid 目标得到 CONNECT 403，没有新增上游准入；实验不会解析这个名称。第三次尝试虽然得到 CONNECT 200，却在证书主机名验证阶段失败，源站 HTTP 处理次数不变。最后用正确配置再次请求，恢复成功。

三条获准隧道都向两个方向转发了字节，但只有两次源站 HTTP 请求完成。DisableKeepAlives 防止其他连接复用掩盖新的 CONNECT 交换；代理响应回调检查实际准入状态，并核对成功响应不含正文分帧字段。程序等待两个方向的复制结束，并显式关闭自行接管的套接字。

作者记录的 macOS、Go 1.27.0 运行通过了全部断言；本轮审阅没有重跑该网络实验，不能把历史记录当成本轮执行证据。请求限时两秒，拨号限时一秒，隧道套接字设置三秒绝对期限。这是隔离的协议实验，不是可以直接部署的公共代理。它没有测试调用方认证、DNS 策略、TLS 拦截、提前注入的缓冲数据、流量整形、持续负载或 HTTP/2、HTTP/3 的 CONNECT 映射，不能据此宣称具备这些生产能力。

来源

RFC 9110：HTTP 语义，CONNECT 准入、目标形式、中继职责和目的地约束，已核验 2026-09-09。
RFC 9112：HTTP/1.1，消息分帧与 CONNECT 隧道切换边界，已核验 2026-09-09。
Go net/http，代理响应观察与接管连接的生命周期，已核验 2026-09-09。
Go net，连接截止时间与 TCP 半关闭，已核验 2026-09-09。
Go crypto/tls，证书验证和 TLS 连接状态，已核验 2026-09-09。

缓存的新鲜度要对着时钟判断

Fri, 03 Dec 2027 00:00:00 +0000

响应经过另一个缓存，不代表自动获得一份全新的新鲜度额度。缓存必须计入交付路径上已经积累的年龄，再增加自己的本地停留时间。否则，每一层看起来都只缓存六十秒，串在一起却可能把旧内容直接复用远超源站预期的时间。判断新鲜度需要明确时间来源，不能只把配置中的秒数当成最终交付保证。

收到的 Age 为 20，共享缓存到 30、私有缓存到 60 即变陈旧。独立陈旧窗口允许响应与异步验证并行，不代表重新新鲜。仅为来源示意；本任务未执行示例。

先算清年龄

Age 估计从响应生成或成功验证以来经过的秒数，其中包括缓存停留与网络传输。收到的 Age 是计算当前年龄的输入，不是在本地存放期间保持不变的计数器。Date 提供响应生成时间；把这些信息联系起来时，时钟同步和实际测得的请求、响应时刻都可能影响结果。只截取一组响应头，不能看到它随后在缓存里又停留了多久。

RFC 9111 给出两条年龄估计路径：接收时刻减去 Date，负数归零，得到表观年龄；收到的 Age 加响应延迟，得到校正年龄值。保守算法取两者较大值，再加本地停留时间。例如请求时刻为一百秒，接收为一百零二秒，Date 为九十五秒，收到的 Age 为十秒，当前时刻为一百零七秒，表观年龄是七秒，校正值是十二秒，当前年龄最终为十七秒。只读原始 Age 就漏算了七秒。

新鲜度寿命也有优先顺序。共享缓存存在 s-maxage 时先用它，否则 max-age 优先于 Expires 减 Date；私有缓存忽略 s-maxage。没有显式过期信息时，在允许的条件下可能使用启发式寿命，但并不存在统一固定时长。只有适用的新鲜度寿命严格大于当前年龄，响应才是新鲜的；恰好相等时已经到达陈旧边界，而不是再多送一次的许可。

坏掉的样子

新鲜不代表适合任意请求。存储许可、网址与 Vary 匹配、验证要求仍然有效。即使寿命设得很长，no-cache 也要求复用前验证。ETag 是验证器，不是免于询问源站的许可。成功重验证可以更新保存的元数据而不重新传正文，但仅仅从另一个缓存收到响应，不能把年龄清零，否则每经过一层就会错误地延长直接复用期限。

提供陈旧响应需要另外的许可，不能把源站故障当成自动授权。must-revalidate 禁止过期后未经成功验证就复用，即使网络断开也不例外。stale-while-revalidate 可以允许在有界的陈旧窗口内一边返回旧内容、一边验证，但仍受适用限制约束，也不会把旧内容重新变成新鲜内容。RFC 9111 已废弃 Warning 字段，因此没有旧式 Warning: 110 不能作为新鲜度证据。

还要区分“存储保留多久”和“直接复用多久”。过期后保留正文，可能有助于重验证或受许可的陈旧窗口，所以缓存后端的淘汰期限可能长于新鲜度寿命。如果调用方直接把这个存储期限当成可返回旧内容的许可，就可能越过响应策略。缓存键仍存在和这次请求可以命中不是一回事，必须检查实际的复用决策。

快速验证

准备 Node.js 与 npm，本次实际使用 Node 26.0.0 和 http-cache-semantics 4.2.0。安装后用 NODE_PATH="$freshness_lab/node_modules" node 执行 JavaScript。程序覆盖的是库内测试时钟，不修改系统时间；输入是虚构元数据，没有网络请求，也不用等待真实时间流逝。只有依赖安装需要联网。

freshness_lab=$(mktemp -d)
npm install --prefix "$freshness_lab" --ignore-scripts --no-audit --no-fund --package-lock=false http-cache-semantics@4.2.0

const assert = require("node:assert/strict");
const CachePolicy = require("http-cache-semantics");

const start = Date.parse("2026-09-07T00:00:00Z");
let clock = start;
class TestPolicy extends CachePolicy {
 now() { return clock; }
}
const request = { url: "https://example.test/news", method: "GET", headers: {} };
const headers = {
 date: new Date(start).toUTCString(),
 age: "20",
 expires: new Date(start + 3600000).toUTCString(),
 "cache-control": "public, max-age=60, s-maxage=30",
};
const shared = new TestPolicy(request, { headers }, { shared: true });
const single = new TestPolicy(request, { headers }, { shared: false });
assert.equal(shared.maxAge(), 30);
assert.equal(single.maxAge(), 60);
for (const [elapsed, sharedHit, privateHit] of [
 [0, true, true], [9, true, true], [10, false, true], [40, false, false],
]) {
 clock = start + elapsed * 1000;
 assert.equal(shared.age(), 20 + elapsed);
 assert.equal(shared.responseHeaders().age, String(20 + elapsed));
 assert.equal(shared.satisfiesWithoutRevalidation(request), sharedHit);
 assert.equal(single.satisfiesWithoutRevalidation(request), privateHit);
 console.log("elapsed:", elapsed, "age:", shared.age(), "reuse:", sharedHit, privateHit);
}

clock = start;
const background = new TestPolicy(request, { headers: {
 age: "20", "cache-control": "public, max-age=30, stale-while-revalidate=20",
} });
clock += 15000;
const decision = background.evaluateRequest(request);
assert.equal(background.timeToLive(), 15000);
assert.equal(background.satisfiesWithoutRevalidation(request), false);
assert(decision.response);
assert.equal(decision.revalidation.synchronous, false);
console.log("stale window: retain 15000 ms, serve and revalidate");
clock += 15000;
assert.equal(background.evaluateRequest(request).response, undefined);
assert.equal(background.evaluateRequest(request).revalidation.synchronous, true);

clock = start;
const oldDate = new TestPolicy(request, { headers: {
 date: new Date(start - 3600000).toUTCString(),
 "cache-control": "public, max-age=60",
} });
assert.equal(oldDate.age(), 0);
assert.equal(oldDate.satisfiesWithoutRevalidation(request), true);
console.log("library limitation: old Date alone does not increase age");

经过零、九、十和四十秒后，计算出的年龄依次是二十、二十九、三十和六十秒。两种模式最初都允许复用；共享模式恰好在三十秒年龄处停止，私有模式到六十秒停止。未来的 Expires 不会覆盖显式寿命。程序同时检查向下游返回的 Age，而不是只断言一个命中布尔值，避免把年龄传播这一半遗漏掉。

独立的陈旧窗口案例达到三十五秒年龄，即超过新鲜期五秒。剩余保留时间是一万五千毫秒，但验证仍然必要。库允许返回缓存响应，同时给出异步重验证决策；它自己不会执行那次网络请求。到五十秒年龄时，窗口许可结束，必须先同步验证。这个结果直接说明后端还能保留条目，不代表可以不经判断地直接使用它。

最后一项有意暴露实现限制：这个库计算年龄时刻意忽略服务器 Date，所以只有一个小时前的 Date、没有 Age 的响应，仍从零开始计龄。它采用收到的 Age 加本地停留时间，不计算实际响应延迟，也不执行上文保守算法中的表观年龄分支。因此，这些断言证明的是固定版本的决策行为，不是完整的 RFC 年龄算法一致性。实际中间层的时序和字段传播仍要另行验证，不能把库测试的通过误写成整条交付链的证明。

来源

RFC 9111：新鲜度，寿命优先级、当前年龄与陈旧响应限制，已核验 2026-09-07。
MDN：Cache-Control，新鲜度与 stale-while-revalidate 指令，已核验 2026-09-07。
http-cache-semantics 4.2.0，保留期限、重验证决策及文档明确说明的 Date 限制，已核验 2026-09-07。

令牌桶限制准入并允许突发

Wed, 01 Dec 2027 00:00:00 +0000

令牌桶限制获准进入的工作量，同时允许积累的额度在短时间内集中使用。它不会自动把请求均匀隔开，不保证成功完成的吞吐，也不限制仍在执行的操作数量；这些分别属于调度和容量问题。桶的两个参数描述的是预算，不是服务一定能够履行的处理能力承诺。

所选事件账本复现原文注入时间、精确算术的单线程模型。在时长为 Δt 的区间内，理想严格模型的获准成本不超过 B 加 rΔt；均匀出流还需单独调度。历史有限范围执行仍为通过，本图不增加运行结果、分布式原子性或云服务保证。

先补充额度，再扣除工作成本

设桶容量 B 为最多能保存的令牌数，回填速率 r 为每秒新增令牌数。每次请求到来，先将额度更新为 min(B, 上次额度 + r × 经过时间)。只有工作成本不超过当前额度才准入，然后扣除成本。本文采用的严格规则下，被拒绝的工作不消耗令牌。

这种计算可以在请求到达时按需进行，不需要后台定时器不断实际投放令牌。长时间空闲也不能积累无限额度，因为容量会截断回填结果。初始额度是一项策略选择：本例从满桶开始，因此允许立即突发；从空桶开始则会得到不同的初始行为，不能漏写这个条件。

突发额度不是峰值速率

对于这个理想严格模型，在长度为 t 的时间区间内，获准工作的总成本不超过 B + r × t。时间越长，突发项的相对影响越小。这不意味着每个一秒窗口都最多允许 r 个请求，也没有额外给出一个独立的瞬时峰值速率上限。

例如容量为三、每秒回填二时，三个单位成本请求可以在同一时刻全部通过，第四个被拒绝；半秒之后又有一枚令牌可用。如果已获准的工作必须均匀离开入口，还需要实际调度器、有界等待队列或其他节奏控制，不能指望令牌桶自动将同时到达的请求排成匀速流。

准入速率也不等于执行并发量。慢请求尚未结束时，令牌仍会继续回填，允许更多工作进入。需要通过合适的并发限制和超时策略保护工作线程、数据库等稀缺资源。同样，已经准入的请求仍可能在下游失败，所以回填速率不能被写成保证成功完成的吞吐。

预算单位和作用范围要一致

一枚令牌不一定对应一个请求，也可以用加权成本代表字节或预计工作量，但容量与回填速率必须使用相同单位。一个成本超过 B 的请求，无论等待多久都装不进这个严格模型的桶。应明确处理这种情况，而不是给出一个实际上永远不能兑现的重试时间。

还要明确预算按谁区分、由谁持有。四个互相独立的满桶，每个保存三枚令牌，可以同时允许十二个请求；它们不是一个全局三令牌桶。共享限流器必须把回填、比较和扣减协调成一次原子决定，仅共享一个计数器而分开执行这些步骤，并不足以保证配额正确。

本地回填应依据经过时间的时钟，不能让墙上时钟校准凭空增加额度，或使记账时间倒退。Python 的单调时钟适合比较两次读取的差值，但其参考原点不是可以在无关机器之间交换的通用时间戳。分布式时钟和状态归属仍需要自己的明确契约。

坏掉的样子

即使长期速率看起来保守，满桶释放的一次突发仍可能压垮脆弱的下游。无界等待队列会把超额需求转化为内存增长与延迟；直接拒绝和延迟整形是两种不同结果，接口应说明调用者会得到哪一种，不能把所有行为都笼统叫作“平滑”。

应一起观察准入成本、拒绝成本、排队、并发量和下游延迟。重试需要遵守限流策略，而不是立即重新制造被拒绝的负载。按尝试工作计费还是按完成工作计费，也是需要明确的选择；失败后退还令牌会改变模型，并引入额外记账要求，不能悄悄当成同一套公式。

托管产品的限制还可能弱于理想算法。Amazon API Gateway 明确说明限流和配额是尽力而为的目标，可能被超过。因此，不能把这里的数学上界宣传成该服务已经验证的硬保证、费用上限，或者任何未经测试部署的严格承诺。

快速验证

保存为 bucket_check.py，用 Python 3.10 以上版本执行 python3 bucket_check.py。原始文章报告使用 Python 3.14.4；2026-10-19 本次审核以 Python 3.12.14 完整运行原样程序并通过。标准库 Fraction 与注入的非递减时间戳让边界计算保持精确，不依赖真实等待。这是单线程准入模型，不是网络限流服务或分布式存储实现。

from fractions import Fraction


class Bucket:
 def __init__(self, capacity, rate):
 assert capacity > 0 and rate > 0
 self.capacity, self.rate = capacity, rate
 self.tokens, self.updated = Fraction(capacity), Fraction(0)

 def take(self, now, cost=1):
 assert now >= self.updated and cost > 0
 self.tokens = min(self.capacity, self.tokens + (now - self.updated) * self.rate)
 self.updated = now
 if self.tokens < cost:
 return False
 self.tokens -= cost
 return True


bucket = Bucket(capacity=3, rate=2)
events = ([(Fraction(0), 1)] * 4 + [(Fraction(1, 4), 1), (Fraction(1, 2), 1),
 (Fraction(3, 2), 2)] + [(Fraction(100), 1)] * 4)
results = [(now, cost, bucket.take(now, cost)) for now, cost in events]
assert [allowed for _, _, allowed in results] == [
 True, True, True, False, False, True, True, True, True, True, False,
]
for now, cost, allowed in results:
 print(f"t={str(now):>3} cost={cost} {'allow' if allowed else 'deny'}")
assert bucket.tokens == 0
marks = sorted({now for now, _ in events})
for start in marks:
 for end in marks:
 if end >= start:
 consumed = sum(cost for now, cost, allowed in results if allowed and start <= now <= end)
 assert consumed <= bucket.capacity + bucket.rate * (end - start)
print("every event-bounded interval obeys admitted cost <= B + r * elapsed")

assert not bucket.take(Fraction(200), cost=4)
assert bucket.tokens == 3
assert bucket.take(Fraction(200), cost=3)
print("cost above capacity never fits; rejection does not consume tokens")

workers = [Bucket(capacity=3, rate=2) for _ in range(4)]
local_admitted = sum(worker.take(Fraction(0)) for worker in workers for _ in range(4))
shared = Bucket(capacity=3, rate=2)
shared_admitted = sum(shared.take(Fraction(0)) for _ in range(16))
assert local_admitted == 12 and shared_admitted == 3
print("four independent full buckets admit", local_admitted, "at once; one shared bucket admits", shared_admitted)

轨迹先允许三个同时到达的请求，拒绝第四个和四分之一秒时的请求；半秒时允许一个，随后在一秒半时允许成本为二的工作。经过很长空闲之后，也只能再放行三枚令牌对应的突发。断言检查所有以事件时间为端点的区间，确认准入成本符合预算上界。

超出桶容量的请求被拒绝，但不会花掉已经积累的额度。最后，四个独立桶同时允许十二个请求，而单个共享的顺序模型只允许三个。这能说明作用范围如何改变配额，却不是对分布式并发扣减正确性的验证，不能把顺序执行的结果当成消除了竞争条件的证据。

本实验没有测试并发竞争、真实时钟调整、队列调度、云平台限流、网络分区或生产性能。它验证的是严格模型的额度更新、分数时间边界和作用范围差异；落地时仍需针对实际状态存储、客户端行为与运行环境重新验证。

来源

RFC 3290，附录 A 的令牌桶预算上界与严格符合性计算，已核验 2026-09-08。
Amazon API Gateway 限流，请求预算、突发与尽力而为限制，已核验 2026-09-08。
Python time，单调经过时间时钟及参考原点边界，已核验 2026-09-08。

Accept 系列头让服务器协商应答

Tue, 23 Nov 2027 00:00:00 +0000

内容协商是在服务器能够实际生成的表示之间进行选择。请求偏好只是选择的输入，并不能证明响应已经满足这些偏好，客户端仍需检查收到的表示。Vary 记录影响复用的请求维度，不负责命名最后选中的格式、语言或压缩方式。把选择输入与响应结果混为一谈，会让排查从一开始就看错字段。

分开看待不同维度

请求偏好	所选表示的响应元数据
Accept	Content-Type
Accept-Language	Content-Language
Accept-Encoding	实际施加内容编码时的 Content-Encoding

这些维度相互独立，请求 JSON 不等于请求英文或 gzip。Content-Language 描述内容所面向受众的语言，不保证每个字符都属于某一种语言。如果服务器只有英文 HTML 和中文 JSON，不能把分别算出的“最优格式”和“最优语言”拼成根本不存在的中文 HTML。应先列清实际可用的完整组合，再定义选择规则；偏好不能凭空增加服务端的生成能力。

质量值范围是零到一，省略时为一，最多允许三位小数。零表示不可接受，不是“稍微不喜欢”。对媒体类型，一个候选的质量值由匹配它的最具体范围决定。显式的 text/html;q=0 不会被更宽泛的 */*;q=1 解禁。如果只是找整串字段里最大的数字，或者拿逗号前第一项，就会丢掉“哪个范围约束哪个候选”的关系，得到看似按权重处理、实际上违反排除条件的结果。

坏掉的样子

缺失某个偏好字段通常表示在该维度上没有偏好，并不等同于显式拒绝。RFC 9110 允许服务器在没有可接受表示时返回 406，也允许忽略该字段，因此默认响应可能仍然无法被客户端使用。承诺严格协商的 API 必须自己明确这项策略。客户端可以表达排除条件，却不能仅靠发出这个字段，强迫所有现网服务器都执行严格拒绝逻辑。

各类字段还存在不同的匹配语义。Accept 使用媒体范围，语言协商需要约定语言标签匹配方式，Accept-Encoding 则有 identity、字段缺失和空值的专门规则。通用列表解析器不会自动补齐所有业务策略。特别是不能把缺失字段悄悄变成一个空集合，再推导出“客户端拒绝一切”。应用选择默认值与解析器返回没有匹配项，是两个需要明确区分的事实。

相同权重也没有一条跨所有服务器通用的顺序规则。应用应让并列时的选择可预测，并实际测试。完整的语言偏好还可能帮助识别用户，因此记录全部偏好档案、把所有可能字段都放进 Vary，并非天然合理。Vary 只处理匹配问题，缓存资格、新鲜度和授权边界仍需各自的规则，不能因为增加了这个字段就认定内容可以共享。

具体程度、排除与候选顺序决定解析结果；端点仍需单独决定如何把无匹配转换成 HTTP 响应。

快速验证

准备 Python 3.11 或更新版本及 POSIX shell，在临时环境安装本次验证的解析器，再用 "$accept_lab/venv/bin/python" 运行 Python 代码。安装需要外网，实验本身不发请求、不启动服务器。它验证的是 Werkzeug 3.1.8 的候选选择行为，不是假装复现任意浏览器或 CDN 的完整实现。

accept_lab=$(mktemp -d)
python3 -m venv "$accept_lab/venv"
"$accept_lab/venv/bin/python" -m pip install Werkzeug==3.1.8

from werkzeug.datastructures import Accept, LanguageAccept, MIMEAccept
from werkzeug.http import parse_accept_header

offers = ["text/html", "application/json"]
cases = [
 (None, "text/html"),
 ("", None),
 ("application/json;q=0.9, text/html;q=0.2", "application/json"),
 ("text/*;q=0.9, text/html;q=0, application/json;q=0.5", "application/json"),
 ("application/json;q=0, text/*;q=0.4, */*;q=1", "text/html"),
 ("application/xml", None),
 ("*/*;q=0", None),
]
for header, expected in cases:
 parsed = parse_accept_header(header, MIMEAccept)
 selected = offers[0] if header is None else parsed.best_match(offers)
 assert selected == expected
 print(repr(header), "->", selected)

denied = parse_accept_header("text/html;q=0, */*;q=1", MIMEAccept)
assert denied.quality("text/html") == 0
assert denied.quality("application/json") == 1
print("specific exclusion:", denied.quality("text/html"), denied.quality("application/json"))

tied = parse_accept_header("application/json, text/html", MIMEAccept)
assert tied.best_match(offers) == "text/html"
assert tied.best_match(list(reversed(offers))) == "application/json"
print("tie: server offer order decides")

languages = parse_accept_header("fr;q=1, zh;q=0.8, en;q=0.5", LanguageAccept)
codings = parse_accept_header("gzip;q=0, br;q=1", Accept)
assert languages.best_match(["en", "zh"]) == "zh"
assert codings.best_match(["gzip", "br"]) == "br"
print("independent axes:", languages.best_match(["en", "zh"]), codings.best_match(["gzip", "br"]))

前七次媒体选择依次得到 HTML、无匹配、JSON、JSON、HTML、无匹配、无匹配。缺失字段时使用 HTML，是调用方明确设定的默认策略；显式为空的 Accept 字段则不采用这个默认值。两个带排除条件的例子说明，更宽泛的范围不会覆盖具体候选的质量值。不提供的 XML 与全体质量值为零都会得到 None；把这个结果转换成 HTTP 406 是端点的职责，不是解析器直接发送了一次错误响应。

并列测试保持请求不变，只反转服务器提供的候选顺序。Werkzeug 在质量值和具体程度都相同时按照这个顺序选择。最后两项分别选出中文和 Brotli，但没有创建它们与某种媒体类型组成的完整表示，也没有执行压缩。语言测试只使用直接标签，不验证地区语言回退；编码测试则刻意不实现 identity 或缺失字段语义。明确这些范围，才能避免从局部输出推导出未被测试的能力。

做真实集成时，应保留这些负向案例，并核对实际发出的请求、返回的元数据和正文。默认情况、受支持的替代项、显式排除项与不可用组合，都应经过真实部署路径测试，再决定哪些请求字段属于 Vary。解析器测试通过，只建立了一个有用的组件契约；它不能代替对整条协商与缓存链路的验收。

来源

RFC 9110：内容协商，字段缺失、质量值、各字段匹配方式与 Vary，已核验 2026-09-07。
Werkzeug Accept 数据结构，具体程度、质量值与并列处理，已核验 2026-09-07。
Werkzeug 头字段解析，解析器与不同字段对应的类型，已核验 2026-09-07。

Webhooks 推送事件而非轮询

Thu, 18 Nov 2027 00:00:00 +0000

Webhook 让提供方在状态变化时通知已注册的接收端。它改变了谁主动发起 HTTP 请求，但单凭这个方向，不能保证必达、即时、有序或只处理一次。真正的运维契约来自提供方的投递规则，以及接收方如何确认和保存工作。理解这层区别，才能知道故障后应该重投、补查还是人工处理。

投递策略由提供方定义

不同服务并不相同。GitHub 不会自动重新投递失败的 webhook，需要合适的重投或对账流程。Stripe 在线上模式下会按指数退避重试最长三天，沙箱的规则则不同。两者都不意味着接收端可以无限期离线而不丢工作。应记录真实重试窗口，以及投递耗尽后由谁发现、如何补回，不能仅凭“用了 webhook”就宣称至少一次保证已经成立。

事件也未必包含完整的当前对象。载荷可能是历史快照，或只提供需要另行查询的标识。事件可能乱序，不同事件编号也可能涉及同一个业务变化。执行不可逆操作之前，应决定是直接应用事件、获取当前状态，还是核对版本后再处理。投递去重与业务操作幂等解决相关但不同的问题，保存一个事件编号不自动等于发货只能发生一次。

先认证、可靠保存，再确认

验签必须遵循提供方的准确格式；要求原始正文时，就使用收到的原始字节。把 JSON 解析后重新编码，可能改变空白或字段顺序，让真实签名失效。TLS 保护到端点的传输，普通服务端认证的 HTTPS 并不证明请求一定来自指定提供方。签名密钥不能写入日志，比较应采用适当方式，轮换也必须遵守提供方流程。

时间戳保护同样是特定协议能力。Stripe 会签入投递时间戳，其库可以检查容差；GitHub 文档定义的正文 HMAC 没有同样的已签名时间戳，因此不能要求所有服务都提供对应头。一次重试可能生成新的投递签名，却仍然代表同一个旧事件。新鲜度按协议检查，重复性按稳定事件身份判断，两者不能相互替代。

新工作返回成功之前，应先可靠地保存到队列或事务性收件表。如果先确认再入队，中间崩溃就会造成发送方停止重试、接收方却丢掉事件的空窗。请求路径要短，但不能为追求短而跳过认证或可靠交接。对于已经保存的合法重复事件，可以返回提供方认可的成功响应，并避免重复副作用；它不应该仅因重复就被当作恶意请求。

坏掉的样子

内存里的已见集合会在重启后消失，也不能协调多个 worker。先记录编号再执行副作用，如果没有可恢复的待处理状态，可能丢工作；先执行副作用再记编号，则可能在崩溃后重复。能使用数据库唯一约束和事务的地方应使用它们，下游操作也需要稳定操作标识支持安全重试。一笔数据库事务本身，不能原子覆盖无关外部系统的付款或发货请求。

密钥轮换只更新部分验签实例，会让真请求间歇性失败。只在计划中的过渡期允许新旧密钥重叠，监控拒绝原因，并按政策移除退役密钥。还要限制正文大小和队列增长。事件虽然都快速收到二百响应，却一直积压不处理，同样是业务故障；投递健康与业务完成必须分别观察，不能让好看的 HTTP 成功率掩盖停滞。

Webhook 签名投递：机制与证据边界。

快速验证

保存为 webhook_verify_demo.py，运行 python3 webhook_verify_demo.py。程序使用明确自定义的 HMAC 格式、公开测试密钥和固定时钟，只依赖标准库与内存状态。它不会连接支付服务，也不是可以直接上线的接收器。这里故意把签名、时效与重复判定的分支隔离，方便检查每一步实际证明了什么。

import hashlib
import hmac
import re

SECRET = b"public-demo-key-not-a-real-credential"
OLD_SECRET = b"public-retired-demo-key"
TOLERANCE_SECONDS = 300
seen_ids = set()


def sign(event_id, timestamp, payload, key=SECRET):
 message = f"{event_id}.{timestamp}.".encode("ascii") + payload
 return hmac.new(key, message, hashlib.sha256).hexdigest()


def accept(event_id, timestamp, payload, signature, now):
 # This is an invented wire format, not a Stripe or GitHub verifier.
 if not re.fullmatch(r"evt_[0-9]+", event_id):
 return "rejected"
 if abs(now - timestamp) > TOLERANCE_SECONDS:
 return "rejected"
 if not re.fullmatch(r"[0-9a-f]{64}", signature):
 return "rejected"
 expected = sign(event_id, timestamp, payload)
 if not hmac.compare_digest(expected, signature):
 return "rejected"
 if event_id in seen_ids:
 return "duplicate"
 seen_ids.add(event_id) # Process-local demonstration, NOT durable acceptance.
 return "accepted"


now = 1_800_000_000
payload = b'{"type":"order.paid","order":"42"}'
fresh = sign("evt_1", now, payload)
assert accept("evt_1", now, payload, fresh, now) == "accepted"
assert accept("evt_1", now, payload, fresh, now) == "duplicate"
# Authenticate even a claimed duplicate before calling it harmless.
assert accept("evt_1", now, payload, "0" * 64, now) == "rejected"
# Change only the body: id and timestamp still match the signed message.
second = sign("evt_2", now, payload)
assert accept("evt_2", now, payload + b" ", second, now) == "rejected"
# Change only the id, leaving body and timestamp intact.
assert accept("evt_3", now, payload, second, now) == "rejected"
for timestamp in (now - 301, now + 301):
 assert accept("evt_4", timestamp, payload,
 sign("evt_4", timestamp, payload), now) == "rejected"
assert accept("evt_5", now, payload,
 sign("evt_5", now, payload, OLD_SECRET), now) == "rejected"
assert accept("evt_6", now, payload, "not-a-digest", now) == "rejected"
assert seen_ids == {"evt_1"}
assert accept("evt_2", now, payload, second, now) == "accepted"
assert seen_ids == {"evt_1", "evt_2"}
print("PASS: authenticated duplicate, independent body/id tampering, stale/future, retired key, malformed digest")

2026-10-19，两份完整中英文围栏均在 Python 3.12.14 下原样运行，断言启用，退出码为零，打印上述 PASS 行且标准错误为空。不要使用 -O 或 PYTHONOPTIMIZE；否则 accept 调用被省略，却仍打印 PASS。原样围栏覆盖真实重复、伪造重复、分别篡改正文与编号、正负三百零一秒、退役密钥及格式错误摘要。另行补充的测试接受包含边界的正负三百秒，并拒绝七种非法事件编号；这些补充用例不在上面的围栏里。每种语言另有五份故意破坏签名、正文、编号、新鲜度或去重保护的变体，均在打印 PASS 前触发断言失败。这些负对照说明测试会发现指定破坏，并不是完整安全证明。

只有认证后的新事件进入集合；损坏投递被拒绝，不阻止同一事件稍后的合法投递。这些结果来自固定时钟、公开测试密钥与进程内状态，不证明持久化接收、跨进程唯一性、HTTP 状态、队列恢复、提供方兼容性或端到端恰好一次副作用。上线前仍须在选定服务与真实存储边界验证这些性质，不能把内存断言当作支付或订单管线验收。

来源

Python assert statement，优化模式省略断言及其内部调用，已核验 2026-10-18。
GitHub：失败的 webhook 投递，不会自动重投，已核验 2026-10-15。
GitHub：验证 webhook 投递，正文 HMAC 与签名比较，已核验 2026-10-15。
Stripe webhooks，重试窗口、原始正文、时间戳、重复与顺序，已核验 2026-10-15。

最少连接衡量连接占用，不代表所有负载

Thu, 11 Nov 2027 00:00:00 +0000

最少连接均衡根据活动连接数选择节点，并遵循具体实现的权重和平局规则。在 nginx 中，least_conn 考虑服务器权重，对于同样合适的节点使用加权轮询。这有助于处理占用连接时间不同的请求，但仍然只是连接维度的测量，不直接知道 CPU、内存压力、排队任务或数据库竞争。算法是否合适，取决于该信号与实际瓶颈有多大关联。

坏掉的样子

把选中的节点称为“最空的服务器”，夸大了信号含义。一条连接可能承载昂贵操作，另一条只是便宜的等待。HTTP 响应关闭后，后台工作还可能继续；多路复用协议也可能把多个操作放在一条连接上。因此，连接少并不能证明后端有足够余量接收下一个昂贵请求。需要保护哪种资源，必须先明确，而不能让算法名称替代容量分析。

计数还是均衡器观察到的上游状态，不是对后端全部客户端的全知统计。通过另一个代理或内部直连到来的工作，可能不在当前视野中。在 nginx 中，worker 范围和上游共享区域配置影响哪些运行状态共享；独立均衡器也不会自动合并观察，形成一个全局最少连接决定。忽略计数范围，会让局部正确的选择被误解成整个集群的最优分配。

权重使只比较原始计数不够准确。权重二的节点可以合理承载比权重一节点更多的活动连接。修改权重表达一种容量假设，并没有测量该假设是否真实。空闲 keepalive 缓存又是另一种数量，不应与这里参与选择的活动连接混淆。应分别识别正在占用的交换、为复用保留的空闲连接，以及真正消耗计算资源的工作。

least_conn 观察加权活动连接，不代表全局资源负载。保持请求须在自身五秒读取截止前释放，当前执行仍待验证。

快速验证

将脚本保存为 check-least-connections.py，准备 Python、Docker 和固定镜像后执行。记录环境使用单个 nginx 1.28.0 worker，没有配置上游 keepalive 缓存，并连接不同端口上的两个 HTTP 节点。后端提供受控响应开关与活动计数，让保持中的工作可以直接观察，不依赖猜测某个睡眠时间是否足够长；不过每个保持中的请求仍须在自身五秒 HTTP 读取超时前获得释放：

from contextlib import contextmanager
from pathlib import Path
from tempfile import TemporaryDirectory
import http.client,json,socket,subprocess,time,uuid

NGINX='nginx@sha256:552e7481ca93ffccd046aa658dbbed22caefbc09c66fa7cd247cbb90b8a5c609'
PYTHON='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],capture_output=True,text=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def wait(predicate):
 deadline=time.monotonic()+15
 while time.monotonic()<deadline:
 try:
 if predicate():return
 except OSError:pass
 time.sleep(.1)
 raise AssertionError('fixture did not become ready')

@contextmanager
def lab(configuration,files=None,backend=None,extra_ports=()):
 name='xbcatm-nginx-'+uuid.uuid4().hex[:10];tags=[name+':proxy',name+':backend'];containers=[name+'-proxy',name+'-backend']
 try:
 with TemporaryDirectory(prefix=name+'-') as directory:
 root=Path(directory);(root/'files').mkdir();(root/'nginx.conf').write_text(configuration)
 for path,content in (files or {}).items():
 target=root/'files'/path;target.parent.mkdir(parents=True,exist_ok=True)
 target.write_bytes(content if isinstance(content,bytes) else content.encode())
 docker('network','create',name)
 if backend is not None:
 (root/'backend.py').write_text(backend)
 (root/'backend.Dockerfile').write_text(f'FROM {PYTHON}\nCOPY backend.py /backend.py\nCMD ["python", "/backend.py"]\n')
 docker('build','--network','none','-f',str(root/'backend.Dockerfile'),'-t',tags[1],str(root))
 docker('run','-d','--name',containers[1],'--network',name,'--network-alias','backend',tags[1])
 wait(lambda:docker('exec',containers[1],'python','-c','import socket;s=socket.create_connection(("127.0.0.1",8081),timeout=.5);s.close()',check=False).returncode==0)
 (root/'Dockerfile').write_text(f'FROM {NGINX}\nCOPY nginx.conf /etc/nginx/nginx.conf\nCOPY files /srv\n')
 docker('build','--network','none','-t',tags[0],str(root))
 docker('run','--rm','--network',name,tags[0],'nginx','-t')
 published=[arg for value in (8080,*extra_ports) for arg in ('-p','127.0.0.1::'+str(value))]
 docker('run','-d','--name',containers[0],'--network',name,*published,tags[0])
 details=json.loads(docker('inspect',containers[0]).stdout)[0]
 binding=details['NetworkSettings']['Ports']['8080/tcp'][0];assert binding['HostIp']=='127.0.0.1';port=int(binding['HostPort'])
 def ready():
 connection=socket.create_connection(('127.0.0.1',port),timeout=.5);connection.close();return True
 wait(ready)
 def request(path,method='GET',headers=None,body=None):
 connection=http.client.HTTPConnection('127.0.0.1',port,timeout=5)
 try:
 connection.request(method,path,body=body,headers=headers or {})
 response=connection.getresponse();return response.status,{k.lower():v for k,v in response.getheaders()},response.read()
 finally:connection.close()
 request.port=port;request.network=name
 request.ports={int(key.split('/')[0]):int(value[0]['HostPort']) for key,value in details['NetworkSettings']['Ports'].items() if value}
 yield containers[0],request
 finally:
 docker('rm','-f',*containers,check=False);docker('image','rm',*tags,check=False);docker('network','rm',name,check=False)

def config(locations,extra=''):
 return 'worker_processes 1;\nerror_log /tmp/error.log notice;\nevents {}\nhttp {\naccess_log off;\n'+extra+'\nserver { listen 8080; root /srv;\n'+locations+'\n}\n}\n'
backend=r'''
from http.server import BaseHTTPRequestHandler,ThreadingHTTPServer
from urllib.parse import urlsplit,parse_qs
import itertools,json,threading
lock=threading.Lock();ids=itertools.count(1);counts={'A':0,'B':0};active={'A':0,'B':0};faults={'A':200,'B':200};gates={}
class Handler(BaseHTTPRequestHandler):
 protocol_version='HTTP/1.1'
 def setup(self):super().setup();self.ident=next(ids)
 def log_message(self,*args):pass
 def do_GET(self):
 parsed=urlsplit(self.path);label=self.server.label;code=200
 if label=='control':
 query=parse_qs(parsed.query)
 with lock:
 if parsed.path=='/fail':faults[query['peer'][0]]=int(query['status'][0])
 if parsed.path=='/release':gates[query['path'][0]].set()
 data={'counts':dict(counts),'active':dict(active),'faults':dict(faults),'held':list(gates)}
 else:
 with lock:
 counts[label]+=1;active[label]+=1;code=faults[label]
 if parsed.path.startswith('/hold/'):gates[parsed.path]=threading.Event()
 if parsed.path.startswith('/hold/'):assert gates[parsed.path].wait(20)
 data={'peer':label,'path':self.path,'connection':self.ident}
 body=json.dumps(data,sort_keys=True).encode();self.send_response(code)
 self.send_header('Content-Type','application/json');self.send_header('Content-Length',str(len(body)))
 self.end_headers();self.wfile.write(body)
 if label!='control':
 with lock:active[label]-=1
for port,label in [(8081,'A'),(8082,'B'),(8083,'control')]:
 server=ThreadingHTTPServer(('0.0.0.0',port),Handler);server.label=label
 threading.Thread(target=server.serve_forever,daemon=True).start()
threading.Event().wait()
'''
from concurrent.futures import ThreadPoolExecutor
extra='''
upstream least { least_conn; server backend:8081; server backend:8082; }
upstream weighted_least { least_conn; server backend:8081 weight=2; server backend:8082; }
'''
locations='''
location /least/ { proxy_pass http://least/; }
location /weighted/ { proxy_pass http://weighted_least/; }
location /control/ { proxy_pass http://backend:8083/; }
'''
with lab(config(locations,extra),backend=backend) as (_,request):
 def get(path):
 status,_,body=request(path);assert status==200;return json.loads(body)
 def state():return get('/control/state')
 results={}
 with ThreadPoolExecutor(max_workers=3) as pool:
 held=pool.submit(get,'/least/hold/first');wait(lambda:sum(state()['active'].values())==1)
 occupied=next(peer for peer,value in state()['active'].items() if value==1)
 quick=[get('/least/quick')['peer'] for _ in range(6)]
 assert all(peer!=occupied for peer in quick),quick
 get('/control/release?path=/hold/first');assert held.result()['peer']==occupied
 wait(lambda:sum(state()['active'].values())==0)
 results['held_peer']=occupied;results['quick_while_held']=quick
 futures=[]
 for index in range(3):
 futures.append(pool.submit(get,'/weighted/hold/w'+str(index)))
 wait(lambda:sum(state()['active'].values())==index+1)
 snapshot=state()['active'];assert snapshot=={'A':2,'B':1},snapshot
 for index in range(3):get('/control/release?path=/hold/w'+str(index))
 results['weighted_active']=snapshot;results['weighted_completed']=[f.result()['peer'] for f in futures]
 wait(lambda:sum(state()['active'].values())==0)
 print(json.dumps(results,sort_keys=True))

第一个请求进入同权最少连接组，并在某个后端处理器中等待。控制端先观察恰好一个活动请求，并识别被占用节点，然后才发送其他请求。初始平局究竟由哪台节点胜出不是主要断言；实验从后端真实状态发现该身份，不把某个偶然的初始顺序写成算法必须遵守的规则。

随后，六个短请求通过同一上游组完成。在第一个请求仍被保持时，它们全部选择另一个节点。之后控制端才放行原响应，并验证它在原节点完成。这展示的是基于持续占用的选择，而不是只统计每台服务器历史上回答过多少次请求。初始请求的释放时机受到明确控制，所以后续分配与活动状态之间的关系可以核对。

第二个上游组把 A 权重设为二、B 设为一。三个请求逐个开始，每个都保持未完成，并确认到达后才启动下一个。活动快照最终为 A=2、B=1，之后三个响应全部放行并成功完成。这说明权重会改变有效比较，策略不是永远选择原始数字最小的节点。观察快照也比仅看最终完成顺序更能说明加权占用。

实验中的 HTTP 交换让每条选中上游连接承载一个活动请求。两个节点端点共享一个可丢弃容器，因此它们的名称不代表不同硬件容量。受控开关证明的是占用与落点，不产生 CPU 基准，也不验证生产机器应该使用某个特定权重。实际节点能承受多少并行操作，仍需根据真实业务成本测量。

比较观测指标与需要保护的资源

先检查真实链路中是什么让上游连接保持活动。关闭响应缓冲时，慢客户端可能让它占用更久；开启缓冲后，代理有时能在客户端下载完成前就读完上游。因此，调整缓冲可能改变最少连接看到的计数，却没有改变应用本身的计算成本。如果忽略这层关系，就容易把连接数变化误当成应用处理能力变化。

应同时测量每个节点的延迟、错误、排队和资源使用。如果某个节点因为依赖失败而变慢，减少新连接可能缓解压力，却不会修复它。节点健康资格与重试策略仍需单独决定。最少连接不是主动健康探测，也不是让恢复节点逐渐回到原权重的升温机制；不能用一个选择算法代替这些不同控制。

最后，验证实际实现的范围和协议。其他产品也叫最少连接的方法，可能具有不同权重、持久性和状态共享规则。通过真实均衡器测试保持请求、释放和加权竞争，再用结果说明所选指标为何适合当前工作负载。算法名称本身不是通用容量保证，只有指标、作用范围与真实瓶颈对应时，选择策略才有可靠依据。

来源

nginx upstream module，least_conn 权重、平局处理、共享区域与活动连接状态，已核验 2026-09-12。
nginx HTTP load balancing guide，最少连接选择及其适用工作负载，已核验 2026-09-12。

multipart 边界把正文切成几段

Wed, 10 Nov 2027 00:00:00 +0000

multipart/form-data 是一种由多个独立 part 组成的 HTTP 表示。一条请求可以同时携带文本字段和二进制文件，但每一段仍要有自己的头部和明确的分隔。客户端选择 boundary 参数，把它写入 Content-Type，再在正文中写出匹配的分隔行。边界只负责分框，不负责判断文件是否安全，也不会替应用决定哪些字段可以提交。

保留线序与原始字节。尾声计入 HTTP 正文预算；完整验证之后再提交。

边界负责把各段框起来

每条分隔线以两个连字符和声明的边界值开头，结束分隔线还要再加两个连字符。multipart 的 boundary 参数是必需的，长度必须为一到七十个允许字符，末尾不能有空白；必要时参数要用引号包住。RFC 7578 要求分隔符不能出现在任何封装 part 中。使用较长、不可预测的值可以把偶然撞值的概率降得很低，但随机并不等于数学上绝对不相撞，生成器仍要遵守语法。

第一个分隔符之前是 preamble，结束分隔符之后是 epilogue。MIME 读取器会忽略这两处内容，因此应用不能把尾声误当成另一个表单字段；不过它们仍是 HTTP 请求正文的字节，应计入整条请求的预算。multipart 解析器返回 EOF，不代表 HTTP 正文已经全部消费完，服务器还要决定怎样处理剩余内容。

每个 part 都有自己的头

form-data 的每个 part 都需要带有包含 name 参数的 Content-Disposition。文件通常还带 filename 与 Content-Type，但文件名是外部输入，不能直接拼进本地路径，也不能保留其中的目录组件。相同字段名可能出现多次，而且顺序有意义；把它们压成一个 map 可能悄悄改变用户提交的表单。part 头部也不能替代对文件真实字节、扩展名、大小和格式的验证。

请使用实现了 MIME 规则的解析器，不要把整个正文按某个字符串直接 split。解析器需要处理 CRLF、带引号的 boundary、最终分隔线、重复名字、损坏头部和任意二进制字节。每个 part 都设置单独上限，同时限制总正文、part 数量、头部和临时存储；全部验证成功后再写数据库或移动上传文件。流式读取只是在不一次性缓存全文时节省内存，如果没有给读取量和临时落盘量设预算，资源风险仍然存在。

MIME 解析器可能有意兼容某些非标准形式。例如，Go 的 multipart 读取器在首个 part 检测到仅使用 LF 的分隔行后，会切换到该兼容模式。因此解析成功不等于严格符合 RFC 语法。下面的夹具只检查列出的错误和限制，不验证所有损坏头部或 boundary 语法违规。

坏掉的样子

浏览器代码的一种常见错误是手动写 Content-Type: multipart/form-data。FormData 已经在正文里生成了边界，但头部没有对应参数，服务器便无法可靠解析。另一个错误是从示例复制一个固定边界，而上传文件恰好包含符合分隔符语法的同样一行；解析器会误认为遇到了新 part，文件因此被截断。缺少关闭分隔线也必须拒绝，不能把前缀当作完整上传。

很多小 part 叠在一起，同样可以消耗大量内存；超长文件名、不支持的 Content-Transfer-Encoding、错误的换行和超大的 epilogue 也会绕过只看单个 part 的检查。不要因为 NextRawPart 成功返回，就认为整条消息已经合法。解析失败发生在副作用之前，拒绝响应中只记录计数与大小，不要把文件正文、Cookie 或认证材料写进日志。客户端上传限制、边缘代理限制和应用解析限制也要明确谁负责哪一层。

若解析器已经把前几个 part 写进临时目录，后一个 part 才发现边界损坏，返回 400 并不会自动删除前面的文件。临时路径应纳入取消和失败清理流程，只有全部验证成功后才移动到最终位置。边界解析正确，只说明找到了各个 part，不能证明内容适合发布；文件类型验证与存储提交仍是独立的检查。

快速验证

历史回环集成示例保持原样，本次完整源码复核没有重跑。此前受限环境中的尝试停在创建监听器这一步；这是历史结果，不是本次重新测试能力所得的结论。仅编译不能证明 HTTP 行为。

把下面程序保存为 multipart_probe.go，用 Go 1.23 或更新版本运行 go run multipart_probe.go。回环服务会构造带引号的 boundary、重复字段、二进制字节、尾声、总量上限和 part 上限；提交计数只是模拟，不会写数据库或磁盘。实验要求字段名称非空，拒绝 Content-Transfer-Encoding，并使用 NextRawPart，避免读取器隐式进行 quoted-printable 解码。

package main

import (
 "bytes"
 "encoding/json"
 "errors"
 "fmt"
 "io"
 "mime"
 "mime/multipart"
 "net/http"
 "net/http/httptest"
 "reflect"
 "runtime"
 "sync/atomic"
 "time"
)

const boundary = "probe:2026"
const totalLimit int64 = 2048
const partLimit int64 = 32
const maxParts = 3

type item struct {
 Name, Filename string
 Body []byte
}

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func build(items []item) ([]byte, string) {
 var body bytes.Buffer
 writer := multipart.NewWriter(&body)
 must(writer.SetBoundary(boundary)) // Deterministic fixture, not a production boundary policy.
 for _, entry := range items {
 var part io.Writer
 var err error
 if entry.Filename == "" {
 part, err = writer.CreateFormField(entry.Name)
 } else {
 part, err = writer.CreateFormFile(entry.Name, entry.Filename)
 }
 must(err)
 _, err = part.Write(entry.Body)
 must(err)
 }
 must(writer.Close())
 return body.Bytes(), writer.FormDataContentType()
}

func main() {
 want := []item{
 {Name: "tag", Body: []byte("first")},
 {Name: "tag", Body: []byte("second")},
 {Name: "upload", Filename: "sample.bin", Body: append([]byte("inline--probe:2026-marker"), 0, 255)},
 }
 valid, contentType := build(want)
 check(contentType == "multipart/form-data; boundary=\"probe:2026\"", "boundary must be quoted")
 var committed, handled atomic.Int64
 server := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 defer r.Body.Close()
 if r.Method != http.MethodPost {
 w.Header().Set("Allow", "POST")
 http.Error(w, "POST required", 405)
 return
 }
 media, parameters, err := mime.ParseMediaType(r.Header.Get("Content-Type"))
 if err != nil || (media == "multipart/form-data" && parameters["boundary"] == "") {
 http.Error(w, "invalid multipart declaration", 400)
 return
 }
 if media != "multipart/form-data" {
 http.Error(w, "multipart/form-data required", 415)
 return
 }
 fail := func(err error) {
 var oversized *http.MaxBytesError
 if errors.As(err, &oversized) {
 http.Error(w, "total body limit", 413)
 } else {
 http.Error(w, "invalid multipart body", 400)
 }
 }
 limited := http.MaxBytesReader(w, r.Body, totalLimit)
 reader := multipart.NewReader(limited, parameters["boundary"])
 var received []item
 for {
 part, err := reader.NextRawPart()
 if err == io.EOF {
 break
 }
 if err != nil {
 fail(err)
 return
 }
 if len(received) == maxParts {
 http.Error(w, "part count limit", 413)
 return
 }
 if part.FormName() == "" || part.Header.Get("Content-Transfer-Encoding") != "" {
 http.Error(w, "named unencoded form part required", 400)
 return
 }
 data, err := io.ReadAll(io.LimitReader(part, partLimit+1))
 if err != nil {
 fail(err)
 return
 }
 if int64(len(data)) > partLimit {
 http.Error(w, "part size limit", 413)
 return
 }
 must(part.Close())
 received = append(received, item{part.FormName(), part.FileName(), data})
 }
 // Multipart EOF need not be HTTP-body EOF: epilogue bytes still count.
 if _, err := io.Copy(io.Discard, limited); err != nil {
 fail(err)
 return
 }
 committed.Add(1) // Simulated acceptance; no files or database writes.
 w.Header().Set("Content-Type", "application/json")
 must(json.NewEncoder(w).Encode(received))
 }))
 server.Config.ReadHeaderTimeout = time.Second
 server.Config.ReadTimeout = 2 * time.Second
 server.Start()
 defer server.Close()
 transport := &http.Transport{}
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 3 * time.Second}
 probe := func(label, media string, payload []byte, status int) {
 before := committed.Load()
 response, err := client.Post(server.URL, media, bytes.NewReader(payload))
 must(err)
 body, readError := io.ReadAll(response.Body)
 closeError := response.Body.Close()
 must(readError)
 must(closeError)
 check(response.Proto == "HTTP/1.1" && response.StatusCode == status, label+": wrong status/protocol")
 delta := int64(0)
 if status == 200 {
 var received []item
 must(json.Unmarshal(body, &received))
 check(reflect.DeepEqual(received, want), label+": names, order, or binary bytes changed")
 delta = 1
 }
 check(committed.Load() == before+delta, label+": rejected body was accepted")
 fmt.Printf("%s: status=%d accepted=%d\n", label, status, committed.Load())
 }
 truncated := bytes.TrimSuffix(valid, []byte("\r\n--"+boundary+"--\r\n"))
 check(len(truncated) < len(valid), "fixture must remove the closing delimiter")
 many, _ := build(append(append([]item(nil), want...), item{Name: "extra", Body: []byte("x")}))
 large := append([]item(nil), want...)
 large[2].Body = bytes.Repeat([]byte("x"), int(partLimit+1))
 largePart, _ := build(large)
 withEpilogue := func(extra []byte) []byte { return append(append([]byte(nil), valid...), extra...) }
 probe("valid quoted boundary", contentType, valid, 200)
 probe("small epilogue", contentType, withEpilogue([]byte("ignored epilogue")), 200)
 probe("missing boundary", "multipart/form-data", valid, 400)
 probe("wrong boundary", "multipart/form-data; boundary=other", valid, 400)
 probe("truncated delimiter", contentType, truncated, 400)
 probe("wrong media type", "application/octet-stream", valid, 415)
 probe("too many parts", contentType, many, 413)
 probe("part too large", contentType, largePart, 413)
 probe("total with epilogue", contentType, withEpilogue(bytes.Repeat([]byte("x"), int(totalLimit))), 413)
 probe("recovery", contentType, valid, 200)
 check(handled.Load() == 10 && committed.Load() == 3, "ten requests must yield three acceptances")
 fmt.Println(runtime.Version())
}

十次请求中只有合法正文、带少量尾声的合法正文和最后恢复请求被接受，共三次提交。第一条结果必须保留两个同名 tag 的顺序，并保留上传内容中的零字节与 255 字节；尾声被解析器忽略，却仍属于 HTTP 正文。缺少或写错 boundary、缺少结束分隔线、错误媒体类型、part 数超限、单 part 超限和总量超限都不会增加提交计数。最后一次成功说明拒绝后服务仍能接受下一条合法请求。历史作者记录报告 macOS、Go 1.27.0 下全部断言、race 和 vet 检查通过，这不代表本次重新执行了这一修订；浏览器 FormData、磁盘清理、损坏 part 头部、边界冲突注入和生产负载没有受检，不能据此宣称这些边界已经安全。

来源

RFC 7578：multipart/form-data，boundary 语法、字段名、文件名和顺序，已核验 2026-09-09。
RFC 2046：媒体类型，分隔符冲突、长度、preamble 与 epilogue 规则，已核验 2026-09-09。
Go mime/multipart，流式读取、原始 part 和 writer 边界，已核验 2026-09-09。
Go mime，媒体类型参数解析与 boundary 提取，已核验 2026-09-09。
Go net/http，请求总量限制、超时和请求生命周期，已核验 2026-09-09。
MDN：FormData，浏览器自动设置 boundary 的行为，已核验 2026-09-09。
Go multipart 读取器源码，isBoundaryDelimiterLine 对首段 LF 的兼容处理，已核验 2026-10-19。

Server-Sent Events 单向推送

Tue, 09 Nov 2027 00:00:00 +0000

Server-Sent Events 在一条持续的 HTTP 响应中传递服务端到客户端的更新。它不把 HTTP 变成双向套接字，自动重连也不会让投递自动具备持久性。事件分帧、连接寿命、历史保留和业务确认，是四个需要分别定义的契约，不能因为都发生在一条流里，就用一个“推送成功”概括。

一份响应包含有边界的文本事件

SSE 响应使用 text/event-stream 类型和 UTF-8 编码。字段按行组织，空行结束一个块；同一事件中的多行 data 会用换行符拼接。以冒号开头的注释行不作为事件数据处理，因此可以承载心跳，而不触发一次业务消息。缺少正确的空行边界，字节到达也可能暂时看不到事件。

event 字段指定事件类型；没有该字段时，默认类型是 message。命名为 update 的事件需要注册 update 监听器，不能只依赖 onmessage。流在事件尚未结束时到达 EOF，也不会仅仅因为连接关闭就派发这份不完整事件。因此，网络层确实收到字节，不等于事件分帧和监听器选择已经正确。

id 字段是字符串，不是协议强制要求单调递增的整数。应用可以选择序号，但排序方式与保留策略仍要自己定义。空 id 会重置保留的编号，而不是确认此前所有业务已经完成。不要把一个用于续传定位的字段，直接解释成数据库提交记录或可靠消息队列的消费确认。

重连仍然依赖历史记录

浏览器重连时可以通过 Last-Event-ID 发送保留的事件编号。这个值是游标提示，不是事务确认。服务端需要一份经过权限约束、仍然保留的历史，以及“从游标之后继续”的明确规则。重新建立连接，无法恢复从未记录的事件，也无法凭空找回已经过期删除的内容。

应定义游标失效后的行为，例如重新获取快照、拒绝续传，或遵循其他明确业务约定。悄悄从最新事件继续，会隐藏中间的缺口。消费者可能还需要去重；收到一个事件，并不能证明后续动作已经恰好执行一次，也不能保证重试后不会再次触发相同副作用。

EventSource 会对可恢复的断连执行重连，HTTP 204 则明确要求停止重连；其他终止条件也存在，并非每种错误都会无限重试。retry 字段表达以毫秒计的重连间隔，但重连调度不是业务投递截止时间，不能拿它充当消息在多少毫秒内必达的承诺。

坏掉的样子

处理函数或中间代理可能缓冲输出，让应用已经生成的事件迟迟不到客户端。源站需要刷新输出，还要沿真实代理路径观察交付。心跳能够帮助维持某些空闲计时边界，却不能推翻固定的请求总期限。订阅队列也要有界，并规定消费者跟不上时是断开、丢弃还是要求重新同步。

认证和 CORS 规则仍然适用。原生 EventSource 提供凭据模式，而不是任意请求头配置，不能假设它接受与 fetch 完全相同的认证参数。多个页面同时订阅时，还要考虑 HTTP/1.x 连接上限与 HTTP/2 流上限；多路复用不会取消连接级资源预算，也不会替服务端解决慢消费者问题。

空行分帧、命名监听器与获授权且保留的历史是不同要求。原文 Go 客户端显式请求续传，不证明浏览器自动重连或持久投递。

快速验证

保存为 sse_probe.go，使用 Go 1.23 或更新版本运行 go run sse_probe.go。本地服务刷新一段注释和一个完整的命名事件，然后让响应继续保持打开。客户端核对精确字节后取消本次请求；后续检查开始之前，服务端必须已经观察到这次断连，避免只检查客户端配置就认定清理成功。

package main

import (
 "context"
 "fmt"
 "io"
 "net/http"
 "net/http/httptest"
 "runtime"
 "sync/atomic"
 "time"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 const firstFrame = ": heartbeat\n\nid: cursor-A\nevent: update\ndata: hello\ndata: world\n\n"
 const replayFrame = "id: cursor-B\nevent: update\ndata: resumed\n\n"
 disconnected, stop := make(chan struct{}), make(chan struct{})
 var handled atomic.Int64
 var firstEnded atomic.Bool
 server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 handled.Add(1)
 cursor := r.Header.Get("Last-Event-ID")
 w.Header().Set("X-Received-Cursor", cursor)
 switch cursor {
 case "cursor-B":
 w.WriteHeader(http.StatusNoContent)
 return
 case "", "cursor-A":
 default:
 http.Error(w, "cursor expired; fetch a fresh snapshot", http.StatusGone)
 return
 }
 w.Header().Set("Content-Type", "text/event-stream")
 w.Header().Set("Cache-Control", "no-cache")
 frame := replayFrame
 if cursor == "" {
 frame = firstFrame
 }
 _, err := io.WriteString(w, frame)
 must(err)
 must(http.NewResponseController(w).Flush())
 if cursor == "" {
 defer firstEnded.Store(true)
 select {
 case <-r.Context().Done():
 close(disconnected)
 case <-stop:
 }
 }
 }))
 defer server.Close()
 defer close(stop)
 transport := &http.Transport{}
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second}
 open := func(ctx context.Context, cursor string) *http.Response {
 request, err := http.NewRequestWithContext(ctx, http.MethodGet, server.URL, nil)
 must(err)
 if cursor != "" {
 request.Header.Set("Last-Event-ID", cursor)
 }
 response, err := client.Do(request)
 must(err)
 check(response.Header.Get("X-Received-Cursor") == cursor, "server must receive the exact cursor")
 return response
 }
 ctx, cancel := context.WithCancel(context.Background())
 defer cancel()
 first := open(ctx, "")
 check(first.StatusCode == 200 && first.Header.Get("Content-Type") == "text/event-stream", "SSE response required")
 buffer := make([]byte, len(firstFrame))
 _, err := io.ReadFull(first.Body, buffer)
 must(err)
 check(string(buffer) == firstFrame && !firstEnded.Load(), "frame must arrive before handler completion")
 cancel()
 must(first.Body.Close())
 select {
 case <-disconnected:
 case <-time.After(2 * time.Second):
 panic("server did not observe disconnect")
 }
 fmt.Println("initial: comment and complete cursor-A frame arrive while response remains open")
 complete := func(cursor string, wantStatus int, wantBody string) {
 response := open(context.Background(), cursor)
 body, readError := io.ReadAll(response.Body)
 closeError := response.Body.Close()
 must(readError)
 must(closeError)
 check(response.StatusCode == wantStatus && string(body) == wantBody, "wrong replay/status response")
 if wantStatus == 200 {
 check(response.Header.Get("Content-Type") == "text/event-stream", "replay must keep the SSE media type")
 }
 fmt.Printf("cursor=%s status=%d\n", cursor, response.StatusCode)
 }
 complete("cursor-A", 200, replayFrame)
 complete("expired", 410, "cursor expired; fetch a fresh snapshot\n")
 complete("cursor-B", 204, "")
 check(handled.Load() == 4, "expected four HTTP requests")
 fmt.Println("explicit replay requests; no browser reconnection or durability claim")
 fmt.Println(runtime.Version())
}

第一个事件含有 cursor-A、update 类型和两行 data。符合规范的 SSE 客户端会派发一个 update，数据为 hello、换行符和 world；前面的注释不是另一个事件。实验核对完整的线上文本块，并确认它们在初始处理函数仍然等待时已经到达，而不是直到 EOF 才一起读到。

第二次请求显式发送 Last-Event-ID: cursor-A，并收到 cursor-B 事件。服务端回显实际收到的游标，以便核对传输值。过期游标得到 410 和重新取得快照的说明，这是本应用选择的策略，不是 SSE 规范规定的游标过期状态。携带 cursor-B 的请求则得到 204 和空正文。

已核验的 macOS、Go 1.27.0 运行中，四次请求全部通过。每次客户端请求限时两秒，等待服务端观察断连也有独立上限。这些短期限是实验保护，不是长期生产订阅的通用配置。响应正文、等待中的处理函数和本地资源都会清理，不会为了展示持续响应而遗留一个无限等待的进程。

Go 程序检查的是字面分帧，并自行构造续传请求，不是浏览器 EventSource 的实现。它没有验证浏览器自动重连、代理缓冲、认证、CORS、历史持久保留、恰好一次业务效果或慢消费者负载。这些能力需要各自额外验收，不能由一次本地流式响应成功来代替。

来源

WHATWG：Server-sent events，分帧、EventSource、事件编号、重连与 HTTP 204，已核验 2026-09-09。
MDN：使用服务端推送事件，命名监听器、流式输出和连接限制，已核验 2026-09-09。
Go net/http，响应刷新、取消与超时边界，已核验 2026-09-09。

请求走私把代理链路带偏

Tue, 19 Oct 2027 00:00:00 +0000

请求走私发生在不同组件对 HTTP 消息边界理解不一致，而且攻击者利用了这种分歧的时候。在代理链中，被前端当作一个请求正文的字节，可能被后端当成另一个请求。关键证据是解析和转发结果不一致，而不只是抓包中出现两条 HTTP 状态行。理解问题时要把字节归属、连接复用和实际影响分开，不能直接用响应数量代替边界分析。

同一字节流，不相容的边界

HTTP/1.1 的组帧有明确规则。合法 Content-Length 可以指定正文长度；chunked 传输编码通过终止块和尾部字段结束。两种机制都没有的请求不包含正文。两种字段同时存在时，Transfer-Encoding 优先，但这是一种可疑组合，需要专门处理，而不是随意接受后继续复用连接。

RFC 9112 允许服务器拒绝同时携带两个字段的请求，或者仅按 Transfer-Encoding 处理；无论如何，响应后都必须关闭连接。中间组件若选择继续转发，必须先移除收到的 Content-Length，并在转发前处理 Transfer-Encoding。入口直接拒绝双重组帧是有用的严格策略，但不能把它说成标准描述的唯一合法行为。

CL.TE 表示前端使用 Content-Length、后端使用 Transfer-Encoding；TE.CL 则相反。其他分歧可能来自冲突长度，或对传输编码语法的不同处理。这些名称描述的是解析器实际行为，不代表报文有两种同样正确的解释。面对不合法输入，不能让每一跳各猜一次，再期待最终边界碰巧一致。

失步可以产生不同影响

完整的隐藏请求可能马上被后端处理，并不必然等待下一位受害者。另一些攻击留下不完整前缀，再与后续流量组合。响应队列污染只是可能后果之一；绕过路由过滤、缓存污染和未授权的后端请求，也可能在没有相同响应错配步骤时造成影响。实际后果取决于连接复用、路由、认证和应用行为，不能用一个实验情节概括全部攻击。

发现额外的后端请求时，应追溯具体字节和连接。仅靠数量不足，因为重试、健康检查、缓存和异步日志都可能让各层记录合理地不一致。后端出现没有对应边缘记录的请求，是调查线索，不是自动确证。应结合关联数据，并在可控实验中使用可辨认的合成请求，排除正常机制之后再判断边界是否被突破。

坏掉的样子

表面的请求头过滤可能漏掉协议转换时产生的歧义。HTTP/2 使用帧，不采用 HTTP/1.1 的 chunked 分界，但降级到 HTTP/1.1 又引入一次必须正确完成的序列化。对 HTTP/2 请求，Content-Length 必须与内容长度一致；无内容响应另有规则，因此不能说换成 HTTP/2 就不再存在任何相关长度检查。

端到端 HTTP/2 能避免部分降级特有的问题，却不是普遍免疫证明。应检查协议转换、统一拒绝畸形消息，并避免在不可恢复的组帧错误后继续复用连接。严格入口可以挡住某条具体攻击路径，即使另一组件仍然宽松；应按真实可达路径评估，不能断言只修一跳永远没有作用，也不能因为某一入口表现正确就忽略其他入口。

curl 显示 HTTP/2，只说明客户端这一段连接使用的协议，无法揭示 CDN 或反向代理后面的链路。类似地，两份响应可能只是正常回答了两个流水线请求。可靠评估必须展示每个组件如何归类字节，以及结果是否跨越原本的请求边界。状态码、计数和协议标签都提供线索，但单独一项无法证明整条代理链的行为。

相同合成字节呈现不相容边界算术。两请求流水线本身不是走私；真实解析器与连接行为仍未测试。

快速验证

保存为 framing_demo.py，执行 python3 framing_demo.py。离线模型在内存里构造字节串，计算两种刻意不一致的边界，并测试一种严格拒绝策略。不向服务器发送任何东西，不创建套接字，合成路径也不指向真实管理端点。Content-Length 根据实际正文计算，而不是复制一个难以复核的固定数字，从而使例子中的计数可以直接核对。

# An in-memory boundary model, not an HTTP parser or network probe.
followup = b'GET /synthetic-next HTTP/1.1\r\nHost: example.test\r\n\r\n'
body = b'0\r\n\r\n' + followup
head = (b'POST /upload HTTP/1.1\r\nHost: example.test\r\nContent-Length: '
 + str(len(body)).encode() + b'\r\nTransfer-Encoding: chunked\r\n\r\n')
wire = head + body
header_end = wire.index(b'\r\n\r\n') + 4
cl_boundary = header_end + len(body)
# This fixture has precisely one zero chunk and an empty trailer section.
te_boundary = header_end + len(b'0\r\n\r\n')
if wire[cl_boundary:] != b'' or wire[te_boundary:] != followup:
 raise RuntimeError('boundary expectations failed')
if cl_boundary == te_boundary:
 raise RuntimeError('the two interpretations must differ')


def reject_dual_framing(header):
 names = {line.split(b':', 1)[0].lower() for line in header.split(b'\r\n')[1:] if b':' in line}
 if {b'content-length', b'transfer-encoding'} <= names:
 raise ValueError('dual framing rejected')


try:
 reject_dual_framing(head)
except ValueError as error:
 print(error)
else:
 raise RuntimeError('ambiguous message accepted')

ordinary_first = b'GET /first HTTP/1.1\r\nHost: example.test\r\n\r\n'
ordinary_pipeline = ordinary_first + followup
first_boundary = ordinary_pipeline.index(b'\r\n\r\n') + 4
if ordinary_pipeline[first_boundary:] != followup:
 raise RuntimeError('ordinary pipeline example failed')
print('CL remaining bytes:', len(wire[cl_boundary:]))
print('TE remaining bytes:', len(wire[te_boundary:]))
print('ordinary pipeline: two intentionally separate requests')
print('PASS: different framing boundaries; dual framing rejected; pipelining distinguished')

按 Content-Length 解释时，剩余字节数是零；按这个固定 chunked 例子解释时，剩余部分是完整的五十二字节合成请求。严格策略拒绝两种字段并存。另一个正常流水线样本有意包含两个请求，不能因为二者同时出现就称为请求走私。成功运行时，PASS 只确认这些有限关系，不声称发现真实漏洞。本轮只核对未变的字节与保留记录，没有执行模型或连接代理。

这不是通用 HTTP 解析器。chunked 用例只有一个零长度块和空尾部区，头部检查也没有实现完整字段语法、重复头规则或协议转换。它在不接触线上服务的条件下说明边界分歧为何重要。集成测试仍需得到授权的隔离链路、真实解析器版本、连接生命周期观察，以及能证明歧义输入无法触发非预期后端操作的负面用例，不能把内存模型当作线上系统的安全报告。

来源

RFC 9112: HTTP/1.1，组帧优先级、中间组件处理、错误与持久连接，已核验 2026-10-15。
PortSwigger: HTTP request smuggling，解析分歧分类及其后果，已核验 2026-10-15。
RFC 9113: HTTP/2，帧内容、畸形消息与 Content-Length 一致性，已核验 2026-10-15。

缓存失效是主动推进，不是祈祷

Thu, 05 Aug 2027 00:00:00 +0000

源站文件改了，并不意味着每个已经保存响应的缓存都会收到通知。失效操作控制的是哪些已存副本还可以继续复用，而不只是更新磁盘上的内容。可靠的发布要区分到期、重新验证、定点移除以及使用新 URL：它们解决不同范围的问题，也没有哪一种能远程擦掉读者已经下载的所有字节。

两个独立私有缓存让移除范围变得具体：改变一个条目，另一个仍可复用。发布并请求新 URL 会建立独立条目，不会擦除旧 URL，也不会自动更新所有读者。

到期不是广播通知

源站发生变化后，一份仍然新鲜的响应可能继续被合法使用。新鲜度由缓存寿命和当前年龄共同决定，年龄计算涉及缓存元数据与经过的时间，并非只从源站的 Date 字段开始倒计时。到期改变的是直接复用时必须满足的条件，既不保证存储介质立即删除条目，也不会让无人访问的缓存主动联系源站。

验证器同样不是内容变化的推送通道。请求需要重新验证时，正确的 ETag 才能帮助源站确认表示未变，或者返回替代正文。浏览器手上的响应还新鲜、没有理由回源时，新增验证器并不能强迫它询问。把源站策略改成 no-cache 或 no-store，也无法追溯修改浏览器之前已经收到的缓存指令。

先确定失效覆盖范围

RFC 9111 要求：缓存收到不安全方法对应的成功或重定向响应时，必须使目标 URI 的已存响应失效。这个义务只涉及该请求实际经过的缓存，不是向整个网络广播。通过另一条接口修改数据库，不会自动覆盖所有派生页面、查询参数变体、不同语言表示和搜索列表，应用需要识别这些真实依赖。

CDN 的清理接口也只管理服务商控制的副本，无法直接清空独立浏览器缓存。应按服务商的实际契约确认受影响的主机、路径、变体以及缓存标签。先让替代内容在源站可用，再发起清理、跟踪完成状态，并比较实际响应正文和缓存状态。接口已经接受清理请求，并不能单独证明它已传播，也不能证明源站已经能返回预期的新字节。

坏掉的样子

如果源站尚未更新就先清理边缘，下一次未命中可能立即把旧内容重新填回去。已经在途的回填也可能和失效操作竞争，具体结果取决于缓存实现。反复执行全站清理不能证明这些竞争已经解决，反而会让更多对象变冷、增加回源负担。应准确圈定受影响对象，并评估清理之后源站需要承担的请求量。

对于静态资产，应先发布带内容指纹的新文件名，再切换 HTML 或清单中的引用。在旧文档仍可能引用旧资产期间，旧文件也应继续可用。新 URL 可以避开旧缓存条目，但前提是读者先拿到更新后的引用文档。只生成一个新文件名，却不更新文档，或者文档本身仍被直接复用，都不会使现有读者自动转向新版本。

涉及机密信息删除时，边界还要更严格。删除源站文件或清理 CDN 不能撤销已经下载的字节，缓存策略也不等于访问授权。应从源头防止敏感响应进入不合适的缓存，而不是泄露后依赖清理挽救。对于紧急修复，要先定义“可见”的对象：新访问者、已经打开的标签页、所有曾下载的副本，不能共享同一种到达保证。

快速验证

准备 Python 3.10 或更新版本及 POSIX shell；实际运行使用 Python 3.14.4、CacheControl 0.14.4 和 Requests 2.34.2。安装下列固定版本后，用 "$invalidation_lab/venv/bin/python" 执行 Python 代码。程序在自动分配的回环端口启动一个 HTTP 服务，并建立两个互不共享存储的内存私有缓存；关闭环境代理，不访问外部服务器，最后关闭客户端、线程和服务。只有依赖安装需要联网。

invalidation_lab=$(mktemp -d)
python3 -m venv "$invalidation_lab/venv"
"$invalidation_lab/venv/bin/python" -m pip install CacheControl==0.14.4 requests==2.34.2

from collections import Counter
from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Thread

import requests
from cachecontrol import CacheControl
from cachecontrol.cache import DictCache

assets = {"/manual.txt": b"A"}
counts = Counter()


class Origin(BaseHTTPRequestHandler):
 def log_message(self, *_):
 pass

 def do_GET(self):
 counts[self.path] += 1
 body = assets.get(self.path, b"missing")
 status = 200 if self.path in assets else 404
 self.send_response(status)
 self.send_header("Cache-Control", "max-age=600" if status == 200 else "no-store")
 self.send_header("Content-Length", str(len(body)))
 self.end_headers()
 self.wfile.write(body)


server = HTTPServer(("127.0.0.1", 0), Origin)
worker = Thread(target=server.serve_forever)
worker.start()
base = f"http://127.0.0.1:{server.server_port}"
caches = [DictCache(), DictCache()]
clients = []
try:
 for cache in caches:
 client = CacheControl(requests.Session(), cache=cache)
 client.trust_env = False
 clients.append(client)

 def check(index, path, status, body, cached):
 response = clients[index].get(base + path, timeout=3)
 assert (response.status_code, response.content, response.from_cache) == (
 status, body, cached
 )

 for index in range(2):
 check(index, "/manual.txt", 200, b"A", False)
 check(index, "/manual.txt", 200, b"A", True)
 assert counts["/manual.txt"] == 2
 print("warm: two independent caches hold A; origin requests=2")

 assets["/manual.txt"] = b"B"
 caches[0].delete(base + "/manual.txt")
 check(0, "/manual.txt", 200, b"B", False)
 check(1, "/manual.txt", 200, b"A", True)
 assert counts["/manual.txt"] == 3
 print("targeted invalidation: cache 0=B; cache 1=A")

 check(1, "/manual.v2.txt", 404, b"missing", False)
 assets["/manual.v2.txt"] = b"B"
 for index in range(2):
 check(index, "/manual.v2.txt", 200, b"B", False)
 check(index, "/manual.v2.txt", 200, b"B", True)
 assert counts["/manual.v2.txt"] == 3
 check(1, "/manual.txt", 200, b"A", True)
 print("new URL: 404 before publication, then both caches=B")
 print("old URL: cache 1 still holds A")
finally:
 for client in clients:
 client.close()
 server.shutdown()
 worker.join()
 server.server_close()

两名客户端各自第一次向源站获取 A，随后命中自己的缓存，所以初始回源总数是两次。把源站内容改成 B 后，只删除零号缓存中精确 URL 对应的条目：零号客户端重新取得 B，一号仍直接返回 A，不会产生新回源。此时旧 URL 的回源总数为三次。结果直接展示了定点移除的作用范围，并没有证明所有副本已经收敛。

新文件名第一次请求返回带 no-store 的 404，特意暴露了“先引用、后发布”的错误顺序。CacheControl 0.14.4 默认可缓存状态也不包含 404，因此本例并未单独验证 no-store 对错误响应缓存的作用。发布这个文件后，两名客户端都能取得并缓存 B；由于前面的错误响应不存储，它不会挡住这次读取。然而一号客户端再访问旧 URL，仍然命中 A。新旧 URL 是不同条目，发布新版本并不意味着旧条目已被擦除。

这是使用真实 HTTP 请求和缓存存储的局部实验，不是 CDN 清理实现，也没有测试浏览器行为、全球传播或在途回填竞态。CacheControl 的安全模型是私有缓存，不能把这段程序扩成多用户共享边缘。实验只证明明确操作过的条目会变化，其他缓存仍按各自收到的策略工作；上线验收必须另外检查真实服务商规则和实际请求链路。

来源

RFC 9111：使已存响应失效，不安全方法与失效范围，已核验 2026-09-07。
CloudFront：清理与版本化文件名，清理边缘不会清空独立缓存，已核验 2026-09-07。
CacheControl 用法，会话与独立缓存存储，已核验 2026-09-07。
CacheControl 安全模型，私有缓存的适用限制，已核验 2026-09-07。
CacheControl 0.14.4 控制器，默认可缓存状态与存储检查，已核验 2026-10-18。

CORS 预检在浏览器发送请求之前检查许可

Fri, 23 Jul 2027 00:00:00 +0000

CORS 预检询问浏览器是否可以发送某个具体的跨源请求，内容包括发起页面的源、计划使用的方法和相关请求头名称。浏览器会先判断预检响应是否允许，再发送实际请求；已有有效预检缓存时，则可能省去这次询问。CORS 同时约束脚本能否读取实际响应。发送许可与响应读取是相互关联的两次检查，但任何一次都不能代替业务身份认证和权限控制。

预检由请求形式触发

源由协议、主机和端口组成，任一部分变化都可能使请求跨源。浏览器不会猜测服务器是否修改数据，再据此决定要不要预检。符合条件的 text/plain 类型 POST 可以直接发送；反而一个仅仅读取数据、却带有 Authorization 头的请求通常需要预检。方法、头部取值以及 Fetch 定义的其他条件共同决定请求是否属于安全列出的范围，“读取不用、写入必用”不是正确规则。

JSON POST 通常需要预检，因为 application/json 不是安全列出的内容类型。浏览器先向目标发出 OPTIONS，携带 Origin、值为 POST 的 Access-Control-Request-Method，以及包含 content-type 的 Access-Control-Request-Headers。这里发送的是未来头部的名称，不是其中可能包含的凭据值。服务器需要允许对应源、方法和相关字段，浏览器才会继续发送这一次实际请求。

两个响应都需要正确配置

受限接口应按完整源进行精确白名单匹配，并在 Access-Control-Allow-Origin 中返回一个允许的源。不能返回逗号分隔的源列表，也不能无条件照抄任意输入。公开给所有来源、且请求不带凭据的资源可以使用星号；携带凭据的访问则需要明确的源和 Access-Control-Allow-Credentials: true。浏览器自己的 Cookie 限制仍然独立生效，CORS 放行不会自动突破这些限制。

实际响应也必须包含适用的 CORS 字段，希望脚本能读取的错误响应同样如此。预检通过，并不能授权脚本读取一个后来缺少许可字段的响应。若返回内容或头部依赖 Origin，还应添加 Vary: Origin，让共享缓存区分不同来源的变体。Access-Control-Max-Age 控制专用预检缓存，并受到浏览器上限约束；不能仅靠普通 HTTP 缓存规则解释为什么某次请求没看到 OPTIONS。

允许客户端发送哪些请求头，与允许脚本读取哪些响应头，是两项独立权限。例如允许 JSON POST，并不自动允许脚本读取自定义的请求标识响应头；需要这类元数据时，应通过 Access-Control-Expose-Headers 明确暴露。把 fetch 改成 mode: "no-cors" 也不是查看被拒响应的办法：它限制请求形式，并返回脚本无法读取状态、头部与正文的不透明响应。调试时应确认需要开放的是发送、正文读取还是响应元数据读取，避免改错字段。

坏掉的样子

认证网关可能因为预检没有携带会话 Cookie 而直接拒绝 OPTIONS。Fetch 的预检通常不会带这些凭据，因此应在要求实际操作登录之前先判断跨源策略。后续业务请求依旧必须通过正常的身份认证和权限检查。为了让预检通过就把真正的写入接口开放给匿名用户，会扩大权限范围，并没有修复原来的策略顺序问题。

符合普通表单条件的 POST 即使无法被脚本读取响应，也可能已经到达服务器。把 CORS 报错解释成“没有发生写入”，可能导致重复提交，也可能让接口缺少必要的 CSRF 防护。这些问题应由业务的防伪请求机制与幂等规则处理。另一个常见故障是代理和应用分别追加允许源字段，最终形成重复字段；两边单独看都像正确配置，组合后的响应却会被浏览器拒绝。

先区分失败边界：预检被拒绝会阻止这次 POST，符合条件的简单 POST 则可能先执行、再发生响应读取失败。Python 夹具核对响应字段和请求计数，不验证浏览器强制规则。这两条浏览器路径仍需单独集成测试；合成夹具不是生产接口。

快速验证

以下 Python 3 实验只监听回环地址，预检允许一个源、POST 方法和内容类型字段，并分别测试不允许的源与请求头。实验中的 POST 处理器故意不做业务认证，用来展示响应读取限制不能保护写入；它不是生产接口，也不应直接对外部署。

根据 RFC 9110 §8.6，204 响应不能携带 Content-Length；本实验的空 403 响应仍明确发送 Content-Length: 0，断言会检查这两种情况。

from http.client import HTTPConnection
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from threading import Thread

ORIGIN = "https://reader.example"

class Handler(BaseHTTPRequestHandler):
 def do_OPTIONS(self):
 names = {s.strip().lower() for s in self.headers.get(
 "Access-Control-Request-Headers", "").split(",") if s.strip()}
 allowed = (self.headers.get("Origin") == ORIGIN
 and self.headers.get("Access-Control-Request-Method") == "POST"
 and names <= {"content-type"})
 self.send_response(204 if allowed else 403)
 if not allowed:
 self.send_header("Content-Length", "0")
 self.send_header("Vary", "Origin, Access-Control-Request-Method, Access-Control-Request-Headers")
 if allowed:
 self.send_header("Access-Control-Allow-Origin", ORIGIN)
 self.send_header("Access-Control-Allow-Methods", "POST")
 self.send_header("Access-Control-Allow-Headers", "content-type")
 self.end_headers()

 def do_POST(self):
 self.rfile.read(int(self.headers.get("Content-Length", "0")))
 self.server.posts += 1
 self.send_response(200)
 self.send_header("Content-Length", "2")
 self.end_headers()
 self.wfile.write(b"ok")

 def log_message(self, *args):
 pass

with ThreadingHTTPServer(("127.0.0.1", 0), Handler) as server:
 server.posts = 0
 worker = Thread(target=server.serve_forever, daemon=True)
 worker.start()
 client = HTTPConnection(*server.server_address, timeout=3)
 try:
 for origin, names, expected in [
 (ORIGIN, "content-type", 204),
 ("https://untrusted.example", "content-type", 403),
 (ORIGIN, "authorization", 403),
 ]:
 client.request("OPTIONS", "/", headers={"Origin": origin,
 "Access-Control-Request-Method": "POST",
 "Access-Control-Request-Headers": names})
 response = client.getresponse()
 response.read()
 assert response.status == expected
 assert response.getheader("Content-Length") == (
 None if expected == 204 else "0")
 assert response.getheader("Access-Control-Allow-Origin") == (
 ORIGIN if expected == 204 else None)
 print("preflight", expected)
 client.request("POST", "/", body="test", headers={
 "Origin": "https://untrusted.example", "Content-Type": "text/plain"})
 response = client.getresponse()
 assert response.read() == b"ok"
 assert response.getheader("Access-Control-Allow-Origin") is None
 assert server.posts == 1
 print("POST reached server without a readable CORS response")
 finally:
 client.close()
 server.shutdown()
 worker.join()

预期依次打印预检状态 204、403、403，然后确认 POST 确实到达了处理器。这验证了服务端的允许判断及响应字段。Python 客户端不执行 CORS，不能用该结果证明浏览器表现。浏览器集成测试中应分别检查 OPTIONS 和后续业务请求：拒绝 JSON 预检应阻止 POST，而符合条件的简单 POST 可以执行后仍让脚本读取失败。解释错误时保留服务端收到请求的证据，才能分清“未发送”与“已执行但不可读”。

来源

Fetch 标准：CORS 协议，浏览器发送许可和响应共享规则，已核验 2026-09-06。
MDN：CORS，预检、凭据和安全列出的请求示例，已核验 2026-09-06。
MDN：预检请求，请求字段和独立预检缓存，已核验 2026-09-06。

404 页面诚实地作答

Sat, 03 Jul 2027 00:00:00 +0000

404 响应有两类读者：软件需要准确的状态码，访客需要一条能继续前进的路径。错误页即使设计精美，也不能用正文弥补错误的 200；状态码正确，也不代表页面可以难以阅读或没有导航。应当同时保证协议和内容诚实，而不是把一个缺失地址误写成成功，或者把正常的缺失当成整个业务故障。

在渲染正文前确定状态

RFC 9110 对 404 的定义是：源站没有找到目标资源的当前表示，或者不愿透露它确实存在。这并不说明缺失是暂时还是永久。如果服务端知道资源很可能已永久删除，可以使用 410；如果地址确实迁移，就把它重定向到对应的新资源。不要把所有未知地址都送往首页，因为这样既掩盖坏链，也会把访客带到与原意无关的地方。

依赖故障和资源缺失不是一回事。数据库连接失败，导致应用无法判断记录是否存在时，应保留对应的服务端错误语义，不能把所有异常统一变成 404。另一方面，权限策略有时会故意用 404 隐藏资源存在性；这种策略要在契约中说明，而不能在错误正文里泄露对象编号、账号归属或权限细节。相同状态码的选择，必须能由业务事实和安全策略解释。

Google 可能把带错误内容的成功响应识别为 soft 404。返回 200 不保证页面被收录，返回 404 也不保证搜索结果立刻消失。工程上可以承诺的是准确状态、明确内容和正确链接，不能把搜索引擎的后续抓取与索引处理说成即时、确定的操作。修复坏链以后，还需要观察实际抓取和访问结果，而不是仅凭模板名称宣布问题消失。

让错误正文独立且安全

页面用一句简短说明、一个真实首页或目录链接帮助读者恢复方向即可。静态站没有必要为了错误页新增搜索表单、第三方组件或数据库查询；本地静态资源和简单模板更容易在故障时继续工作。API 则应返回已经约定的机器可读错误格式，并保留 404，不能返回一份状态为成功的 HTML 让调用方误判。

状态必须先于正文写入。在 Go 中，如果还没有调用 WriteHeader，第一次写正文会隐式选择 200，后面再试图设置 404 就已经太晚。HEAD 应保持与 GET 相同的状态和适用的表示元数据，但不能传输正文。直接打开某个错误模板文件，只证明那个文件能显示，并不证明真实的缺失请求会进入正确处理器。

坏掉的样子

把所有路径重写到首页，会让缺失文章、脚本和样式表都得到假成功；反向代理也可能把源站的 404 改成自己的 200 错误页。另一个常见问题是处理器先输出页面框架，随后才发现文件不存在。排查时应在实际入口请求一个确定不存在的地址，先禁止自动跟随重定向，再对照正常地址的第一份响应，而不是只看浏览器最终显示了什么。

404 还可能进入缓存。标准允许它在合适条件下进行启发式缓存，过长的负缓存寿命会让刚创建或恢复的页面继续显示不存在。应该明确选择缓存策略；no-store 可以阻止新的存储，却不会主动清除之前已经存入缓存的响应。正文不要未经转义回显查询串，日志也不要记录可能携带认证信息的完整地址。按规范化路径统计缺失请求，避免把每一个随机 URL 都变成新的指标标签。

一份响应，两类读者。依据原文与明确限制静态绘制；未为本图重跑原文夹具。

快速验证

把下面程序保存到临时工作目录的 not_found_probe.go，运行 go run not_found_probe.go。它只启动一个回环 HTTP/1.1 服务，不自动跟随跳转，恢复动作仅改变内存标志。/soft-miss 是故意留下的反例，用于证明“正文像错误页”不足以验证状态，不能把该路由当成推荐实现。

package main

import (
 "fmt"
 "io"
 "net/http"
 "net/http/httptest"
 "runtime"
 "strconv"
 "strings"
 "sync/atomic"
 "time"
)

func must(err error) {
 if err != nil {
 panic(err)
 }
}

func check(ok bool, message string) {
 if !ok {
 panic(message)
 }
}

func main() {
 const missing = `<!doctype html><title>Not found</title><h1>Page not found</h1><a href="/">Home</a>`
 var restored atomic.Bool
 server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
 status, body, media := 404, missing, "text/html; charset=utf-8"
 switch r.URL.Path {
 case "/":
 status, body = 200, "<!doctype html><title>Home</title><h1>Home</h1>"
 case "/gone":
 status = 410
 case "/moved":
 status = 308
 w.Header().Set("Location", "/")
 case "/offline":
 status, body = 503, "Service temporarily unavailable"
 case "/soft-miss":
 status = 200 // Deliberate bug: the body alone cannot identify success.
 case "/restored":
 if restored.Load() {
 status, body = 200, "Restored resource"
 }
 default:
 if strings.HasPrefix(r.URL.Path, "/api/") {
 media, body = "application/json", `{"error":"not_found"}`
 }
 }
 if r.Method != "GET" && r.Method != "HEAD" {
 status, body = 405, "Method not allowed"
 w.Header().Set("Allow", "GET, HEAD")
 if media == "application/json" {
 body = `{"error":"method_not_allowed"}`
 }
 }
 w.Header().Set("Content-Type", media)
 w.Header().Set("Cache-Control", "no-store")
 w.Header().Set("Content-Length", strconv.Itoa(len(body)))
 w.WriteHeader(status) // Status must be committed before writing the body.
 if r.Method != "HEAD" {
 _, err := io.WriteString(w, body)
 must(err)
 }
 }))
 defer server.Close()
 transport := &http.Transport{}
 defer transport.CloseIdleConnections()
 client := &http.Client{Transport: transport, Timeout: 2 * time.Second,
 CheckRedirect: func(*http.Request, []*http.Request) error { return http.ErrUseLastResponse },
 }
 probe := func(method, route string, status int, media string) (*http.Response, string) {
 request, err := http.NewRequest(method, server.URL+route, nil)
 must(err)
 response, err := client.Do(request)
 must(err)
 body, readError := io.ReadAll(response.Body)
 closeError := response.Body.Close()
 must(readError)
 must(closeError)
 check(response.StatusCode == status && response.Proto == "HTTP/1.1", "wrong status or protocol")
 check(response.Header.Get("Content-Type") == media, "wrong media type")
 check(response.Header.Get("Cache-Control") == "no-store", "fixture must not reuse negative responses")
 check(!strings.Contains(string(body), "do-not-echo"), "request query leaked into error page")
 fmt.Printf("%s %s: %d, body=%d bytes\n", method, request.URL.Path, status, len(body))
 return response, string(body)
 }
 const html = "text/html; charset=utf-8"
 probe("GET", "/", 200, html)
 get, body := probe("GET", "/missing?hint=do-not-echo", 404, html)
 check(body == missing && strings.Contains(body, `href="/"`), "missing page must offer a real home link")
 head, empty := probe("HEAD", "/missing", 404, html)
 check(empty == "" && head.ContentLength == get.ContentLength, "HEAD must preserve status and length without a body")
 probe("GET", "/assets/missing.css", 404, html)
 _, api := probe("GET", "/api/missing", 404, "application/json")
 check(api == `{"error":"not_found"}`, "API must not receive an HTML success page")
 probe("GET", "/gone", 410, html)
 move, _ := probe("GET", "/moved", 308, html)
 check(move.Header.Get("Location") == "/", "known move must name its target")
 probe("GET", "/offline", 503, html)
 soft, softBody := probe("GET", "/soft-miss", 200, html)
 check(softBody == missing && soft.StatusCode != get.StatusCode, "negative control must expose a soft 404")
 probe("GET", "/restored", 404, html)
 restored.Store(true)
 _, recovered := probe("GET", "/restored", 200, html)
 check(recovered == "Restored resource", "restored resource must no longer return 404")
 rejected, _ := probe("POST", "/missing", 405, html)
 check(rejected.Header.Get("Allow") == "GET, HEAD", "method rejection must describe allowed methods")
 apiRejected, apiError := probe("POST", "/api/missing", 405, "application/json")
 check(apiRejected.Header.Get("Allow") == "GET, HEAD" && apiError == `{"error":"method_not_allowed"}`, "API method errors must retain JSON")
 fmt.Println("PASS: thirteen requests; missing, moved, unavailable, and restored remain distinct")
 fmt.Println(runtime.Version())
}

十三次请求覆盖正常首页、HTML 缺失、API 缺失、丢失的静态文件、已删除资源、已知迁移和暂时不可用。GET 与 HEAD 对缺失资源返回相同状态和声明长度，但 HEAD 没有正文；查询参数标记不会出现在页面中。soft-miss 的正文和真实 404 完全一致，错误的 200 才揭示它的问题。随后同一个恢复地址从 404 变为 200，说明资源重新出现后不应继续返回缺失；POST 则独立返回 405 和 Allow，避免把方法错误混为不存在，API 的方法错误也保持 JSON 格式。

这些断言已在 macOS、Go 1.27.0 下运行通过。实验使用 no-store 声明，并不实现真实浏览器或 CDN 缓存，因此不能据此证明负缓存已经失效，也没有验证搜索引擎索引和线上代理配置。发布前还需要在网站真实服务链路上分别检查中英文正常路径和虚构路径，确认服务器没有因为美化错误页而改变协议语义。

来源

RFC 9110：HTTP 语义，404、410、HEAD 和表示语义，已核验 2026-09-09。
RFC 9111：HTTP 缓存，负响应存储和缓存控制，已核验 2026-09-09。
MDN：404 Not Found，资源缺失和自定义错误页，已核验 2026-09-09。
Google Search：HTTP 与网络错误，soft 404 和索引行为，已核验 2026-09-09。
Go net/http，响应状态提交和重定向控制，已核验 2026-09-09。

Canonical URL 标识首选表示

Sat, 26 Jun 2027 00:00:00 +0000

同一文档可能由多个地址提供：跟踪参数、别名主机或末尾斜杠变化，都可能不改变有意义的内容。canonical 链接用于指出合适重复表示中的首选版本，帮助接收方理解它们的关系，但不会自动重定向 HTTP 请求，也不能强制搜索引擎采用声明的网址。只有目标与周围信号符合真实内容关系，这份声明才有价值；标签存在本身并不等于规范化已经完成。

先确定身份，再写标签

先决定哪个公开网址代表这份文档，再让站内链接和相关 sitemap 条目与这个选择一致。不能机械删除所有查询参数：跟踪参数可能多余，语言、页码或商品选择却可能实质改变表示。如果没有比较含义就把它们全部折叠到一个地址，会把不同文档指向错误的首选页面。规范化应当反映资源关系，而不是只让网址看起来更短。

HTML 中应把带有 rel="canonical" 的 link 元素放入有效 head，并提供清晰目标。对于 PDF 等其他表示，也可以用 HTTP Link 响应头表达这一关系。优先采用完整公开网址，减少 base 地址或部署前缀造成的歧义。生成时应依据站点预期的公开配置，而不是意外把代理内部主机名写进页面。实际发布结果需要再次检查，不能仅查看模板参数。

canonical 链接关系本身不要求目标必须位于同一个源站。跨域声明需要仔细审查内容与控制关系，声明一个值并不能证明拥有目标。对翻译页面，如果同语言的合适规范页面存在，通常应选择该语言目标。语言替代与内容重复是不同关系，把所有中文页面都指向英文首页，会抹掉有意义的文档区别，不能称为准确的去重处理。

坏掉的样子

声明目标可能报错、继续重定向，或者又指向另一个 canonical。模板、插件和响应头各自生成声明，也可能产生相互冲突的值。应检查完整响应，而不是只搜索有没有一个标签。首选目标需要能够使用，声明也要与实际表示一致。多个位置各自维护相同事实时，更应明确权威来源，避免一次修改只更新了其中一处。

普通链接关系不会改变原始地址的可访问性，除非路由另外配置了行为。如果旧路径需要对所有客户端迁移，就应设置合适的 HTTP 重定向，并验证它对方法的影响；如果变体仍有用途，也可以继续成功响应并提供 canonical。不能把元数据提示等同于跳转、访问授权，或者爬虫必须执行的命令。用户与搜索系统可能观察到不同层面的结果。

搜索引擎会综合多种信号，也可能选择另一份规范网址。因此，标签正确不等于收录已经收敛。应区分源站实际提供的声明与搜索服务报告的选择，排查站内链接、sitemap、跳转或语言元数据是否互相矛盾。发生分歧时，不应只是在更多位置重复添加同一个标签，而应先确认它表达的内容关系是否真实且一致。

重复表示汇合，语言保持区分。依据原文与明确限制静态绘制；未为本图重跑原文夹具。

快速验证

保存为 canonical.py 并执行 python3 canonical.py。脚本创建临时回环 HTTP 源站，用 Python HTML 解析器读取实际响应，提供英文文档、跟踪参数变体、中文文档和两个故意不一致的元数据案例。本地网址只是演示身份，并不会提交给搜索引擎，也没有检查任何真实搜索账号或收录记录。

from html.parser import HTMLParser
from http.client import HTTPConnection
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from threading import Thread
import json


class Canonical(HTMLParser):
 def __init__(self):
 super().__init__()
 self.urls = []

 def handle_starttag(self, tag, attrs):
 values = dict(attrs)
 if tag == 'link' and 'canonical' in values.get('rel', '').split():
 self.urls.append(values.get('href'))


class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 origin = f'http://127.0.0.1:{self.server.server_port}'
 chinese = self.path.startswith('/zh/')
 target = '/zh/article' if chinese else '/article'
 if self.path == '/zh/wrong':
 target = '/article'
 link = f'<link rel="canonical" href="{origin}{target}">'
 if self.path == '/conflict':
 link += f'<link rel="canonical" href="{origin}/another">'
 title = '中文文章' if chinese else 'English article'
 data = f'<!doctype html><html lang="{"zh" if chinese else "en"}"><head><meta charset="utf-8"><title>{title}</title>{link}</head><body><h1>{title}</h1></body></html>'.encode()
 self.send_response(200)
 self.send_header('Content-Type', 'text/html; charset=utf-8')
 self.send_header('Content-Length', str(len(data)))
 self.end_headers()
 self.wfile.write(data)

 def log_message(self, *args):
 pass


server = ThreadingHTTPServer(('127.0.0.1', 0), Handler)
thread = Thread(target=server.serve_forever)
thread.start()
try:
 origin = f'http://127.0.0.1:{server.server_port}'

 def fetch(path):
 connection = HTTPConnection('127.0.0.1', server.server_port, timeout=5)
 try:
 connection.request('GET', path)
 response = connection.getresponse()
 text = response.read().decode()
 parsed = Canonical()
 parsed.feed(text)
 return response.status, response.getheader('Location'), text, parsed.urls
 finally:
 connection.close()

 variant = fetch('/article?utm_source=example')
 primary = fetch('/article')
 translated = fetch('/zh/article')
 assert variant[:2] == (200, None) and variant[2] == primary[2]
 assert variant[3] == [origin + '/article']
 assert translated[3] == [origin + '/zh/article']
 wrong = fetch('/zh/wrong')
 conflict = fetch('/conflict')
 assert wrong[3] != [origin + '/zh/article']
 assert len(conflict[3]) == 2
 print(json.dumps({'variant_status': variant[0], 'variant_redirect': variant[1],
 'same_representation': variant[2] == primary[2],
 'english_target': variant[3], 'chinese_target': translated[3],
 'wrong_language_detected': True, 'conflicting_targets': len(conflict[3]),
 'search_engine_selection_tested': False}))
finally:
 server.shutdown()
 thread.join()
 server.server_close()

跟踪参数变体返回二百，没有 Location 响应头；其字节与英文主页面一致，canonical 指向 /article。中文页面则指向 /zh/article。这同时验证了示例里的重复关系，以及两种语言表示之间的区别。仅提供 canonical 不会让这次 HTTP 请求变成跳转，因此客户端取得的仍是所请求地址的成功响应。

错误语言案例把中文响应指向英文目标；冲突案例则输出两个不同的规范目标。两者都仍然返回二百，所以只看状态的检查会漏掉问题。断言通过读取元数据并比较预期语言映射，识别了这两种具体不一致，并没有猜测搜索引擎面对错误声明时必定采用哪一种处理方式。

这里没有爬虫参与，小解析器也不是完整规范化验证器。实验说明服务器提供了什么声明、怎样响应，不代表 Google 选择了哪个 canonical，更不代表排名结果。调整生产身份之前，应把等价内容、公开目标、已有入口和语言关系一起审阅，并保留原地址或有意设置的重定向，避免元数据整理悄悄破坏用户已经保存的链接。

来源

RFC 6596: canonical link relation，首选表示及 canonical 链接关系的范围，已核验 2026-09-13。
Google: consolidate duplicate URLs，规范网址信号、目标一致性与语言处理，已核验 2026-09-13。

Cookie 标记约束支持它们的客户端

Thu, 17 Jun 2027 00:00:00 +0000

Secure、HttpOnly 和 SameSite 分别描述支持这些规则的浏览器如何限制 Cookie。服务端收到的是最终的名称与值，而不是一张证明这些限制已经执行的证书。浏览器行为与服务端授权必须分开：Cookie 完全可能被正确发送，但当前请求的业务动作仍然不被允许，不能把出现 Cookie 头当成全部安全条件已经满足。

分开看设置、发送与脚本读取

Secure 限制 Cookie 通过安全连接发送，通常就是 HTTPS。现代浏览器 Cookie 规则还会拒绝从不安全语境设置 Secure Cookie；localhost 等开发例外应在目标浏览器中核对，而不能推广为任意明文主机都可信。这不仅是发送阶段的标记。一次 HTTPS 重定向无法撤回此前明文请求已经泄露的令牌，因此应结合 HTTPS 与适当的 HSTS 策略，而不是让两者互相替代。

HttpOnly 阻止通过 document.cookie 等非 HTTP 脚本接口读取 Cookie，但不会禁止浏览器把它附到符合条件的脚本请求上。被注入的同源 JavaScript 即使读不到令牌，也仍可能以用户身份发起操作。因此必须单独预防和限制 XSS；HttpOnly 减少的是其中一条窃取路径，并不是把脚本注入漏洞消除了。

SameSite 增加请求语境限制。Strict 通常允许同站请求，Lax 还允许使用安全方法的跨站顶层导航。显式 Lax 不会仅因为某次跨站 POST 是从顶层页面发起，就让 Cookie 自动附上。None 去掉这一项限制，但在支持规则的浏览器中必须搭配 Secure。第三方 Cookie 阻止、存储分区以及 Fetch 的凭据模式，仍可能阻止发送，不能把 None 理解成任何请求都无条件携带。

站点与来源不是同一回事

对于普通 HTTPS 域名，相关的带协议站点边界由协议和可注册域构成。两个 HTTPS 兄弟子域可以同站，却仍然不同源。端口变化也会造成不同源，而未必改变站点。因此，Strict 不承诺排除所有跨源请求；同站兄弟应用被攻陷，仍然是评估 CSRF 防护时必须考虑的场景，不能只测试完全无关的外部域名。

省略或填写无效 SameSite，也不能可移植地等同于显式 Lax。规范允许针对最近创建、没有显式值的 Cookie 使用兼容模式，使部分不安全方法的顶层请求也携带它。常见的两分钟窗口是面向实现的兼容性限制，不是每一种浏览器都必须采用的保证。应写出预期值，并测试真正支持的浏览器版本，而不是依靠默认值的模糊印象。

坏掉的样子

会修改状态的 GET 在 Lax 下仍有危险，因为跨站顶层的安全方法导航可以携带 Cookie。修改状态应采用合适的方法和服务端 CSRF 防护。反过来，Strict 可能扣住跨站身份提供方回调所需的 Cookie。要检查真实的重定向链与回调方法；并非所有单点登录都会失败，而且单独打开一个书签，也不能证明发生了跨站重定向。

应使用身份库支持的关联校验与回调设计，而不是不加区分地放宽主要会话。Origin 或 Fetch Metadata 校验可以发挥作用，但需要明确处理头字段缺失、兼容客户端和合法跨站流程。非浏览器客户端可以伪造这些头，所以它们是浏览器语境信号，不是凭据。已经持有被盗会话令牌的客户端，需要认证和撤销机制来处理，不能指望再检查一次 SameSite 就把它识别出来。

快速验证

把代码保存为 cookie-flags.py，使用 Python 3.11 或更新版本执行 python3 cookie-flags.py。它使用真实标准库 CookieJar 与虚构响应元数据，不发送网络请求。目的在于展示这个 HTTP 客户端的 Cookie 政策与浏览器政策之间的差别，不是建立一个假的浏览器，再把模型结果冒充成真实浏览器行为。

from email.message import Message
from http.cookiejar import CookieJar
from http.cookies import SimpleCookie
from urllib.request import Request


class Response:
 def info(self):
 headers = Message()
 for value in [
 "secure_sid=synthetic; Path=/; Secure; HttpOnly; SameSite=Lax",
 "strict_pref=synthetic; Path=/; SameSite=Strict",
 "insecure_none=synthetic; Path=/; SameSite=None",
 ]:
 headers.add_header("Set-Cookie", value)
 return headers


jar = CookieJar()
jar.extract_cookies(Response(), Request("https://app.example.com/login"))


def outgoing(url):
 request = Request(url)
 jar.add_cookie_header(request)
 header = request.get_header("Cookie", "")
 parsed = SimpleCookie()
 parsed.load(header)
 assert "SameSite" not in header and "HttpOnly" not in header
 return set(parsed)


assert outgoing("http://app.example.com/") == {"strict_pref", "insecure_none"}
assert outgoing("https://app.example.com/") == {
 "secure_sid", "strict_pref", "insecure_none"
}
manual = Request("http://app.example.com/",
 headers={"Cookie": "secure_sid=synthetic"})
assert manual.get_header("Cookie") == "secure_sid=synthetic"
print("PASS: CookieJar filters Secure; it does not enforce SameSite")
print("PASS: request headers omit attributes; a manual header bypasses the jar")

CookieJar 在 HTTP 上扣住 secure_sid，在 HTTPS 上发送它，即使它带有 HttpOnly。与此同时，它接受 insecure_none，也会在没有建模页面同站语境的情况下发送 strict_pref。后两项结果展示的是这个客户端的局限，不是浏览器的预期。手动构造 Cookie 头还可以完全绕过 CookieJar。本实验没有建立任何服务端响应或浏览器结果，也没有验证真正的 CSRF 拒绝路径。

Secure、HttpOnly 与 SameSite 约束不同浏览器边界。文章中的 CookieJar 使用合成元数据，不发送网络请求：HTTP 不携带 secure_sid，HTTPS 携带；它不执行 SameSite。服务端授权需要单独判断。

验收浏览器时，应使用隔离的同站与跨站测试页面、虚构取值，分别检查 Cookie 能否存入以及实际是否随请求发送。覆盖顶层 GET、POST 回调、嵌入式 fetch，以及应用使用的凭据模式。用 curl 伪造 Sec-Fetch-Site 头无法证明 SameSite 已被执行，一个任意 HTTP 状态码也不能证明 Cookie 被接受或业务动作已获授权；应收集与问题直接相关的两端证据。

来源

Cookie 规范草案第 22 版，存储、发送、SameSite 与可选兼容行为，已核验 2026-10-15。
Python CookieJar，客户端 Cookie 处理及其文档列明的协议范围，已核验 2026-10-15。
OWASP CSRF 防护，SameSite 局限、来源与 Fetch Metadata 防御，已核验 2026-10-15。

HTTP keep-alive：复用同一条连接

Fri, 28 May 2027 00:00:00 +0000

HTTP 持久连接允许多次请求与响应复用同一条连接，减少重复的 TCP 建连；使用 HTTPS 时，也可能省去新的 TLS 协商。收益取决于网络延迟、响应大小、服务端处理时间以及池中是否已经有可用连接。连接复用不会消除业务计算，也没有承诺某个套接字永远保持打开。讨论优化之前，先明确观察的是哪一段连接、哪个协议版本。

原文 HTTP/1.1 实验中，/one、/two、/close 共用一个套接字，/four 使用新套接字。四次响应均为 200，Content-Length: 2，正文 ok 均在下一次请求前完整读完；/close 的 Connection: close 让后续请求重新建连。这是本地顺序实验的实测结果，不是 HTTP/2 或端到端代理证据。原样实验已于 2026-10-17 在 Python 3.14.4 上复验。

完整报文才允许复用

HTTP/1.1 默认允许持久连接，除非某一方发送 Connection: close，或实际关闭传输连接。通常不必额外添加 Connection: keep-alive。客户端连接池可以保留空闲连接，供符合源、代理、证书和池策略的后续请求使用。连续执行两次独立的命令行程序，通常不会共享内存中的连接池，因而不能凭两次响应成功就断言已经复用。

复用的前提是双方都能识别每条消息的结束位置。响应可以通过准确的 Content-Length、分块传输编码，或无正文响应的协议规则界定边界。如果只能依赖关闭连接表示正文结束，这条连接自然无法留给下一次请求。客户端需要读完响应正文；服务器需要读完请求正文，或者关闭连接。残留字节一旦被当成下一条消息解析，问题就从性能退化变成报文错位。

HTTP 持久连接与 TCP keepalive 也是两回事。后者在传输连接空闲足够久后发送探测，帮助识别失联的对端，不负责 HTTP 消息分界，也不能覆盖代理或应用自己的空闲超时。仅仅打开操作系统的探活选项，并不会让一个已经被代理回收的连接重新可用。排查时应分别记录应用层关闭、传输层错误和连接池回收动作。

顺序复用还不同于流水线请求。客户端可以等前一个响应完成后再发送下一条请求，同时一直使用相同连接。HTTP/1.1 流水线允许提前发送请求，但响应仍须按序返回。因此，仅有持久连接并不具备 HTTP/2 多路复用提供的独立响应流，不能把两者的并发收益混为一谈。

每一跳管理自己的超时

空闲超时按照具体实现的规则衡量无活动时间，请求截止时间则限制一次操作能等待多久，两者需要独立配置。反向代理同时拥有客户端连接和上游连接，两侧可能使用不同协议、连接池和超时。因此，浏览器到边缘复用了连接，并不能证明边缘到源站也复用；看到一侧握手减少，也不能直接解释另一侧的延迟变化。

连接池应结合已知的服务端限制提前淘汰空闲连接，但始终可能发生竞态：客户端刚发送下一条请求，服务器恰好开始关闭。监控应同时包含新建连接数、成功复用次数、连接重置、池占用和请求延迟。保留更久可以减少握手，也会占用文件描述符与内存。应依据实际请求间隔和资源预算确定保留策略，不能仅凭“站点很忙”推导一个固定超时。

坏掉的样子

正文长度错误可能让读取方一直等待，或让下一条响应的开头混进上一条正文。遇到请求挂起时先检查消息分界，再考虑调大超时。另一个常见故障是调用方放弃流式响应，却既不读完也不关闭，导致池中的连接长期占用。此时服务器还有处理能力，新的请求却全在客户端等空位，扩大服务端容量无法解决这个问题。

陈旧连接报错不代表服务器没有执行请求。如果支付已经提交而响应在回程丢失，自动重连并原样重发可能重复扣款。是否重试必须依照方法语义和业务幂等契约判断，不能把传输异常当成回滚证明。HTTP/2 虽然可以在连接上复用多个流，却禁止 Connection、Keep-Alive 等 HTTP/1.x 专属字段；把这些头搬进 HTTP/2 配置没有优化意义。

快速验证

下面是可直接运行的 Python 3 实验：服务器绑定系统分配的回环端口，客户端连续请求四次，结束后关闭测试服务器。它不需要外部服务；内置 HTTP 服务器只用于本地验证，不是部署配置。

验证记录（2026-10-17）：原样实验在 macOS arm64 的 Python 3.14.4 上通过，运行时启用断言和仅限回环的限制。下文所述的验证范围限制仍然适用。

from http.client import HTTPConnection
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from threading import Thread

class Handler(BaseHTTPRequestHandler):
 protocol_version = "HTTP/1.1"

 def do_GET(self):
 self.server.connections.append(self.connection)
 self.send_response(200)
 self.send_header("Content-Length", "2")
 if self.path == "/close":
 self.send_header("Connection", "close")
 self.end_headers()
 self.wfile.write(b"ok")

 def log_message(self, *args):
 pass

with ThreadingHTTPServer(("127.0.0.1", 0), Handler) as server:
 server.connections = []
 worker = Thread(target=server.serve_forever, daemon=True)
 worker.start()
 client = HTTPConnection(*server.server_address, timeout=3)
 try:
 for path in ("/one", "/two", "/close", "/four"):
 client.request("GET", path)
 response = client.getresponse()
 assert response.status == 200
 assert response.read() == b"ok"
 sockets = server.connections
 print("reused:", sockets[0] is sockets[1] is sockets[2])
 print("new after close:", sockets[2] is not sockets[3])
 finally:
 client.close()
 server.shutdown()
 worker.join()

预期输出是 reused: True 和 new after close: True。前两次完整读取正文后，第三次仍使用同一个套接字；第三次收到显式关闭指示后，第四次重新建连。这里比较的是服务器持有的连接对象，不是容易误读的响应耗时。实验只证明本地 HTTP/1.1 的复用与关闭行为，没有覆盖 TLS、浏览器连接池或生产代理；部署验证仍应逐跳检查连接标识与新建连接计数。

来源

RFC 9112：HTTP/1.1 连接管理，消息分界、持久连接、重试和关闭，已核验 2026-09-06。
MDN：HTTP/1.x 连接管理，持久连接及其资源成本，已核验 2026-09-06。
RFC 9113：HTTP/2 连接专属字段，HTTP/2 消息禁止使用的字段，已核验 2026-09-06。

Retry-After 告诉你何时再试

Tue, 04 May 2027 00:00:00 +0000

Retry-After 告诉客户端，在发起后续请求之前应当等待多久。它是调度信号，不证明下一次请求一定成功，也不证明重放原操作是安全的。客户端仍然需要截止期限、尝试次数政策，以及哪些操作可以重试的判断，不能把这些责任都交给一个响应头。

结合响应语境解释字段值

RFC 9110 允许非负十进制整数秒数，或者 HTTP 日期。秒数从收到响应之后开始计算，不是从发出原请求时算起；日期则表示一个绝对 UTC 时刻，因此正确解释它依赖客户端墙上时钟足够准确，不能把两个形式都当成“从请求开始算多久”。

发送方必须使用首选的 IMF-fixdate 格式。解析 HTTP 日期的接收方还必须接受两种旧格式，其中旧 RFC 850 格式的两位年份需要遵守五十年解释规则。负数、小数秒和任意文字，都不是合法的 delay-seconds；零和已经过去的日期，则不要求增加服务器指定的等待时间。

配合 503 时，该字段估计服务还会对客户端不可用多久；配合 3xx 响应时，它要求在发送重定向请求之前至少等待相应时间。RFC 6585 另行允许 429 携带 Retry-After，但这里是可选字段，不是每一条限流响应都必须包含的内容。

尊重等待时间，但不无限等待

一个合法等待值可能长于调用方剩余期限。客户端可以停止重试并报告失败，或者在另有授权的流程中安排后续处理；不能只是为了符合本地上限，就缩短服务器要求的等待，然后提前发起请求。很长的值并不自动等于格式错误，也可能是真实的维护安排。

把绝对日期换算成等待时长后，执行调度和经过时间记账应使用单调时钟。真正开始下一次尝试之前，还应重新检查期限，并为这次请求本身保留完成时间。时钟偏差、响应传输和调度延迟，都说明计算出的计划时间与实际请求时间不是同一份证据。

如果字段缺失或无法使用，有界客户端政策可以采用自己的退避规则。但那是客户端的选择，不是服务器给出的恢复估计。必须明确最多尝试几次、总共允许耗费多久，避免一个可选字段让暂时失败变成没有终点的重试循环。

相同等待值仍可能让调用者同时回来

如果成千上万的客户端几乎同时收到相同等待值，它们仍可能在同一个时刻返回。Retry-After 本身不会把这些请求自动摊开到恢复窗口。可以在尊重要求的等待后增加非负抖动，或者用其他不早于该边界的调度方式，但不能向前减掉等待来制造错峰。

组合本地退避和服务器提示时，需要同时保留两者约束。示例取本地退避与解析出的等待值中较大者，再添加正向抖动。注入的偏移量展示的是调度关系，不是实际分布式流量的测量结果，也不是对某个生产环境抖动范围的推荐。

坏掉的样子

当原请求结果未知时，盲目重放写操作可能重复产生副作用。429、503 和 Retry-After 都不会赋予操作幂等保证；重复非幂等工作之前，需要依据应用自己的重试契约，包括操作标识或去重规则，不能只检查响应头是否存在。

不同客户端库的自动重试和重定向行为也不相同。应验证真实客户端会处理哪些状态、方法和字段。实验政策只对 429 或 503 后的 GET、HEAD 做重试计划，明确不跟随重定向、不重放 POST。这是一个有界示例政策，不是 HTTP 所有幂等方法的完整名单。

非法值、巨大等待、过时日期、耗尽的截止期限和次数上限，都应进入测试。应观察真正的请求尝试与等待，而不是认为配置了响应头就代表客户端已经遵守。服务器也可能在估计时间之后仍不可用，所以重试流程需要一个清楚的终止结果。

至少等待服务端提示和本地退避要求的较大值，再增加非负抖动。这里是注入的调度计划，不是真实定时重试或安全重放保证。

快速验证

保存为 retry_check.py，用 Python 3.10 以上版本执行 python3 retry_check.py。仅用标准库。代码向自己创建的回环 HTTP 服务发送真实请求，使用固定测试日期和注入时钟，结束后停止服务；不会实际等待到下一次重试，也不访问外部服务。

验证记录（2026-10-17）：原样实验在 macOS arm64 的 Python 3.14.4 上通过，运行时启用断言和仅限回环的限制。下文所述的验证范围限制仍然适用。

from datetime import datetime, timedelta, timezone
from email.utils import format_datetime, parsedate_tz
from http.client import HTTPConnection
from http.server import BaseHTTPRequestHandler, HTTPServer
import re
from threading import Thread


UTC = timezone.utc
REFERENCE = datetime(2026, 9, 8, 12, 0, 0, tzinfo=UTC)


def delay_seconds(value, received_wall):
 if value is None:
 return None
 value = value.strip(" \t")
 if re.fullmatch(r"[0-9]+", value):
 # Huge decimal values become infinity and fail the bounded retry budget.
 return float(value)
 parts = parsedate_tz(value)
 if parts is None:
 return None
 year, month, day, hour, minute, second = parts[:6]
 old_date = re.fullmatch(r"[A-Za-z]+, [0-9]{2}-[A-Za-z]{3}-([0-9]{2}) [0-9:]{8} GMT", value)
 if old_date:
 now = datetime.fromtimestamp(received_wall, UTC)
 year = now.year // 100 * 100 + int(old_date[1])
 if (year, month, day, hour, minute, second) > (
 now.year + 50, now.month, now.day, now.hour, now.minute, now.second
 ):
 year -= 100
 if not 0 <= second <= 60:
 return None
 try:
 stamp = datetime(year, month, day, hour, minute, min(second, 59), tzinfo=UTC)
 stamp += timedelta(seconds=(second == 60) - parts[9])
 except (ValueError, OverflowError):
 return None
 return max(0.0, stamp.timestamp() - received_wall)


def retry_at(status, method, value, received_wall, monotonic_now, remaining, attempt, jitter=0.25):
 assert attempt >= 1 and jitter >= 0
 if status not in (429, 503) or method not in ("GET", "HEAD") or attempt >= 3:
 return None
 server_delay = delay_seconds(value, received_wall)
 wait = max(server_delay or 0.0, 2 ** (attempt - 1)) + jitter
 if wait >= remaining:
 return None
 return monotonic_now + wait


wall = REFERENCE.timestamp()
for value in ("Tue, 08 Sep 2026 12:00:07 GMT", "Tuesday, 08-Sep-26 12:00:07 GMT",
 "Tue Sep 8 12:00:07 2026"):
 assert delay_seconds(value, wall) == 7
assert delay_seconds("Sunday, 06-Nov-94 08:49:37 GMT", wall) == 0
assert delay_seconds("Monday, 08-Sep-70 12:00:00 GMT", wall) == (
 datetime(2070, 9, 8, 12, tzinfo=UTC).timestamp() - wall
)
assert delay_seconds("Sat, 31 Dec 2016 23:59:60 GMT",
 datetime(2016, 12, 31, 23, 59, 59, tzinfo=UTC).timestamp()) == 1
for invalid in ("-1", "1.5", "later", "", "٣", "Tue, 31 Feb 2026 12:00:00 GMT"):
 assert delay_seconds(invalid, wall) is None
assert delay_seconds(" 0003\t", wall) == 3
assert retry_at(503, "GET", "9" * 5000, wall, 100, 10, 1) is None
assert retry_at(503, "GET", "3", wall, 100, 2, 1) is None
assert retry_at(503, "POST", "3", wall, 100, 10, 1) is None
assert retry_at(503, "GET", "3", wall, 100, 10, 3) is None
print("both delay forms, obsolete dates, year interpretation, and invalid values are checked")
print("an oversized wait, exhausted deadline, POST, or attempt cap stops this retry policy")

cases = {
 "/seconds": (429, "3"),
 "/date": (503, format_datetime(REFERENCE + timedelta(seconds=7), usegmt=True)),
 "/invalid": (503, "later"),
 "/missing": (503, None),
 "/redirect": (307, "3"),
 "/ready": (200, None),
}
visited = []


class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 visited.append(self.path)
 status, value = cases.get(self.path, (404, None))
 self.send_response_only(status)
 self.send_header("Date", format_datetime(REFERENCE, usegmt=True))
 if value is not None:
 self.send_header("Retry-After", value)
 if status == 307:
 self.send_header("Location", "/ready")
 self.send_header("Content-Length", "0")
 self.end_headers()

 def log_message(self, *_):
 pass


with HTTPServer(("127.0.0.1", 0), Handler) as server:
 thread = Thread(target=server.serve_forever, kwargs={"poll_interval": 0.05})
 thread.start()
 try:
 for route, expected in (("/seconds", 103.25), ("/date", 107.25),
 ("/invalid", 101.25), ("/missing", 101.25), ("/redirect", None)):
 client = HTTPConnection(*server.server_address, timeout=2)
 try:
 client.request("GET", route)
 response = client.getresponse()
 response.read()
 planned = retry_at(response.status, "GET", response.getheader("Retry-After"),
 wall, 100, 10, 1)
 assert planned == expected
 print(route, "status", response.status, "planned monotonic time", planned)
 finally:
 client.close()
 assert "/ready" not in visited
 finally:
 server.shutdown()
 thread.join(timeout=2)
 assert not thread.is_alive()

same_delay = [retry_at(429, "GET", "3", wall, 100, 10, 1, jitter=0) for _ in range(4)]
spread = [retry_at(429, "GET", "3", wall, 100, 10, 1, jitter=j) for j in (0.1, 0.2, 0.3, 0.4)]
assert same_delay == [103] * 4
assert len(set(spread)) == 4 and min(spread) > 103
print("identical server delays synchronize plans; injected positive jitter spreads them:", spread)

解析检查覆盖列出的秒数、日期、旧格式、年份解释、闰秒和非法输入，但 email.utils 还接受 HTTP 日期语法之外的输入。因此这是宽松的调度演示，不是严格的 RFC 语法验证器；生产环境需要明确自己的接收和拒绝政策。有界政策会放弃超过剩余期限的等待、POST 重放，以及达到次数上限后的再次尝试。日期和时钟是明确设定的测试数据，并没有修改机器时间，也不代表运行当时的真实 UTC 时刻。

本地 429 返回三秒等待时，从注入的单调时间一百计算出 103.25 的计划时间；日期形式的 503 得到 107.25。缺失或非法字段使用已经声明的本地退避，重定向则不会被自动跟随。四个相同延迟产生四个 103 的计划，注入正向抖动后得到 103.1 到 103.4，展示的是可以验证的计划差异。

这些是响应与调度决定测试，不是实际按时重试的验收。真实时钟校准、网络分区、代理行为、生产抖动分布和业务操作去重仍未测试。落地时应观察最终发出的请求，不能把一组正确的计算时间，直接当成客户端已经在复杂网络中按时重试的证据。

来源

RFC 9110，5.6.7 和 10.2.3 节定义 HTTP 日期和 Retry-After，已核验 2026-10-15。
RFC 6585，429 中可选的 Retry-After，已核验 2026-10-15。
Python 邮件工具，日期解析、UTC 偏移和时间戳格式化，已核验 2026-10-15。

HTTP · XB 现场笔记

nginx 验证器是否可靠，取决于表示身份是否准确

坏掉的样子

快速验证

让部署保持验证器契约

延伸阅读

来源

gzip、HTTP/2 与 Brotli 需要分别验证

坏掉的样子

快速验证

先确认能力，再比较性能

延伸阅读

来源

先决定让 nginx 跳转客户端，还是在内部重写

坏掉的样子

快速验证

测试客户端真正收到的转换

延伸阅读

来源

Cache-Control 是缓存与源站之间的约定

双方都要读同一份约定

坏掉的样子

快速验证

延伸阅读

来源

CONNECT 方法打开一条裸隧道

在正确的边界切换语义

看不见正文，仍然占用资源

坏掉的样子

快速验证

延伸阅读

来源

缓存的新鲜度要对着时钟判断

先算清年龄

坏掉的样子

快速验证

延伸阅读

来源

令牌桶限制准入并允许突发

先补充额度，再扣除工作成本

突发额度不是峰值速率

预算单位和作用范围要一致

坏掉的样子

快速验证

延伸阅读

来源

Accept 系列头让服务器协商应答

分开看待不同维度

坏掉的样子

快速验证

延伸阅读

来源

Webhooks 推送事件而非轮询

投递策略由提供方定义

先认证、可靠保存，再确认

坏掉的样子

快速验证

延伸阅读

来源

最少连接衡量连接占用，不代表所有负载

坏掉的样子

快速验证

比较观测指标与需要保护的资源

延伸阅读

来源

multipart 边界把正文切成几段

边界负责把各段框起来

每个 part 都有自己的头

坏掉的样子

快速验证

延伸阅读

来源

Server-Sent Events 单向推送

一份响应包含有边界的文本事件

重连仍然依赖历史记录

坏掉的样子

快速验证

延伸阅读

来源

请求走私把代理链路带偏