浏览器如何比较缓存的 URL？
How do browsers compare URLs for caching?
具体来说，URL的哪些部分用于比较。假设我在 https://www.example.com/a/b/test.css 提供 CSS 样式表，并为 cache-control、max-age 等提供适当的 HTTP headers。当用户转到以下每个 URLs 之后，它们中的哪一个将提供缓存文件？
https://www.example.com/a/b/test.css
https://www.example.com/a/b/test.css?abc=123
https://www.example.com/a/b/test.css#abc=124
基本上，我要问的是，当浏览器决定是否使用缓存时，是否比较 URL 字符串的 "search" 和 "hash" 部分资源。此外，这种比较逻辑是否跨浏览器一致，或者是某些标准的一部分？
RFC 7234 states:
The primary cache key consists of the request method and target URI.
更重要的是，RFC 7230 explains that:
The target URI excludes the reference's fragment component, if any,
since fragment identifiers are reserved for client-side processing
将这两个放在一起，前两个资源不等同（因为查询是 URI 的一部分）。最后一个引用与第一个相同的资源。这是标准指定的行为。
但是，请注意以前版本的规范 stated:
Note: Section 13.9 of [RFC2616] prohibited caches from calculating
heuristic freshness for URIs with query components (i.e., those
containing '?'). In practice, this has not been widely
implemented.
这表明某些实现不会缓存第二个示例，除非特别说明它是可缓存的。
具体来说，URL的哪些部分用于比较。假设我在 https://www.example.com/a/b/test.css 提供 CSS 样式表，并为 cache-control、max-age 等提供适当的 HTTP headers。当用户转到以下每个 URLs 之后，它们中的哪一个将提供缓存文件？
https://www.example.com/a/b/test.css
https://www.example.com/a/b/test.css?abc=123
https://www.example.com/a/b/test.css#abc=124
基本上，我要问的是，当浏览器决定是否使用缓存时，是否比较 URL 字符串的 "search" 和 "hash" 部分资源。此外，这种比较逻辑是否跨浏览器一致，或者是某些标准的一部分？
RFC 7234 states:
The primary cache key consists of the request method and target URI.
更重要的是，RFC 7230 explains that:
The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side processing
将这两个放在一起，前两个资源不等同（因为查询是 URI 的一部分）。最后一个引用与第一个相同的资源。这是标准指定的行为。
但是，请注意以前版本的规范 stated:
Note: Section 13.9 of [RFC2616] prohibited caches from calculating heuristic freshness for URIs with query components (i.e., those containing '?'). In practice, this has not been widely implemented.
这表明某些实现不会缓存第二个示例，除非特别说明它是可缓存的。