我正在使用Deno 1.26中新添加的CacheStorage API。我的理解是，这基本上起到了Map<Request, Response>的作用。我质疑Request对象的哪些方面是决定它是否匹配的因素。例如，是否只考虑URL？我开始思考，如果一个带有Accept-Encoding: gzip, deflate, br的特定URL的请求进来，然后响应包含一个带有头Content-Encoding: gzip的gzip压缩体，会发生什么。如果相同的URL被其请求包含例如Accept-Encoding: deflate的客户端请求，会发生什么。CacheStorage API是否仅根据URL匹配此项，并返回带有gziped主体的响应？
我在Deno测试了这个场景，结果似乎就是这样。Deno似乎只根据URL进行匹配，而不关心Content-Encoding标头。所以我的问题是，这是否是Deno实现中的一个bug，或者它是否只是web API中的一次疏忽。也许我想得太多了，实际上它没有意义，因为现在使用的所有HTTP客户端实际上都支持gzip压缩响应。
Request中考虑的唯一与缓存项算法匹配的标头是Vary标头。
外部客户端不调用CacheAPI本身。您的应用程序代码能够完全管理这些调用。
以下是关于制作一个使用CacheAPI并支持对其客户端的压缩和未压缩响应的应用程序的一些想法：
- 内部使用
CacheAPI的特定压缩 - 要求客户端支持编码或添加对按需解压缩的支持(请参阅下一项(
- 当从
Cache向客户端提供Response时…- 如果客户端指定接受相同的编码，则直接从
Cache返回压缩响应 - 如果客户端指定它接受其他编码，但不接受应用程序内部使用的编码，则解压缩并可能使用不同的算法重新压缩，以返回所需的
Response - 如果客户端没有指定它接受的编码，则从
Cache解压缩Response以返回客户端
- 如果客户端指定接受相同的编码，则直接从