我们正在使用Azure CDN来提供图像，我正在尝试理解为什么图像被Web浏览器强化缓存，即使图像响应中没有Cache-Control或Expires标头。
例如，为Azure CDN中的图像返回以下响应标头：
HTTP/1.1 200 OK
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Content-MD5: KuQCJm6GQyEjejWwmRgRwQ==
Content-Type: image/jpeg
Date: Tue, 21 Nov 2017 00:15:57 GMT
Etag: 0x8D523228F0F4C42
Last-Modified: Sat, 04 Nov 2017 01:22:47 GMT
Server: ECAcc (meb/A744)
X-Cache: HIT
x-ms-blob-type: BlockBlob
x-ms-lease-status: unlocked
x-ms-request-id: 00822b7c-001e-0045-4194-61d246000000
x-ms-version: 2009-09-19
Content-Length: 5143
<<image data>>
正如您所看到的，返回了 Etag 标头，但没有缓存控制或过期标头。
当从浏览器（Chrome）跟踪网络流量（使用Fiddler）时，我们没有看到对这些图像的任何后续请求。
我对Etags的理解是，应该将此图像的后续请求发送回服务器（弱缓存），然后如果文件未更改，服务器可以返回 304未修改响应
任何人都可以对此有所了解吗？
答案 0 :(得分：1)
我认为您需要标头缓存控制：必须重新验证以使浏览器检查源并且如果没有更改则返回304 mot修改。
但就缓存而言，这不是最佳选择。
你最好通过QS更改使这些js无效（＆＃34; v = ??＆＃34;）或设置一个简短的expires / max-age标题（60/120秒，或者你能处理的任何内容）部署，5分钟???）。
将expires标头与etags结合使用仍然意味着浏览器在到期后收到304未从服务器修改的内容。