CacheStorage API是否关注Content-Encoding头？Deno实现存疑

一、Request对象哪些属性影响缓存匹配？ #

CacheStorage的缓存匹配并非仅以URL为依据，而是遵循HTTP缓存语义，会考虑Request对象的多个核心属性：

• 请求方法：仅GET/HEAD请求会被缓存（POST/PUT等默认不参与缓存）
• 完整URL：包括协议、主机域名、路径、查询参数
• 关键请求头：Accept、Accept-Encoding、Accept-Language这类内容协商头，以及Authorization、Cookie（当credentials模式开启时）
• 请求模式（mode）：比如same-origin、no-cors
• 凭证模式（credentials）：是否携带Cookie、HTTP认证信息

它的匹配逻辑远复杂于Map<Request, Response>的对象引用匹配，而是基于HTTP请求的语义特征。

二、关于Accept-Encoding头的缓存匹配问题 #

你测试的场景中，同URL但不同Accept-Encoding的请求命中了同一缓存，核心原因在于响应头的Vary字段：
Web标准规定，只有当响应携带Vary: Accept-Encoding时，CacheStorage才会将Accept-Encoding头作为缓存匹配的依据。如果原响应没有设置这个头，缓存系统会默认认为不同Accept-Encoding的请求对应的是同一资源，直接返回缓存的响应。

所以你遇到的情况，大概率是测试时的响应未包含Vary: Accept-Encoding头，Deno的实现是符合Web标准的，并非bug；如果响应明确设置了该头但Deno仍忽略，那才是实现层面的问题。

三、关于Web API设计的疑问 #

这并非Web API的疏漏，而是缓存机制的设计逻辑：内容协商的缓存区分需要依赖响应端明确声明Vary字段，以此告知缓存系统哪些请求头需要纳入匹配判断。如今主流HTTP客户端都支持gzip等压缩，很多服务端可能默认不返回Vary: Accept-Encoding，但这是服务端的配置选择，而非API本身的问题。

内容的提问来源于stack exchange，提问作者Chris_F