在我的应用程序中，我有一个GET请求，以从api端点获取图像。
这些是服务器为图像返回的标头。
访问控制允许来源：http://localhost:3001
缓存控制：公共，max-age = 43200
连接：保持活动状态
Content-Disposition：附件； filename = blah.jpg
内容长度：567829
内容类型：图片/ jpg
日期：2019年6月22日星期六17:05:18 GMT
ETag：“ 1560511770.8223343-567829-3517588627”
到期日期：2019年6月23日，星期日，格林尼治标准时间
最后修改时间：2019年6月14日，星期五，格林尼治标准时间
服务器：gunicorn / 19.7.1
严格的运输安全性：max-age = 31536000; includeSubDomains
变化：起源
其他一些有用的信息：
GET端点受基于jwt的身份验证保护。在这种情况下，我希望它默认情况下不会被缓存，但是由于服务器明确提供了Cache-Control: public，因此我认为现在应该对其进行缓存。
api终结点与UI应用程序域具有不同的域。我已经在可以更改的其他服务器上进行了尝试，并且跨源请求对于缓存似乎并不重要。
图像请求不是从浏览器发送的，而是与其他任何GET请求一样从应用程序发送的。这样做是因为端点落后于身份验证。这也意味着将使用responseType: "blob"来获取此图像，然后创建一个Blob网址并将其设置为image src。如果blob网址每次都不同（我可以看到），是否会导致不使用资源的缓存版本？我希望甚至在创建blob url之前就可以解决cahing的问题，所以没关系。
响应大小可以作为一个因素吗？我不会这样。
UI应用程序在http上运行，而api端点在https上运行。这可能是个问题吗？
Vary: Origin标头不应禁止缓存，因为我是从同一来源发出请求的
我希望无论用户身份验证如何，此响应都将被缓存43200秒，但是甚至不会为具有相同令牌的同一用户缓存（每次我单击按钮再次获取它时，我都不会在Chrome的“网络”标签上看不到任何表明它是从磁盘或内存缓存中提取的指示）
根本没有缓存此响应的原因是什么？
编辑：
经进一步查询，似乎Content-Disposition: attachment标头可能是罪魁祸首，如here所述，它不适用于Chrome缓存。正在Firefox中缓存资源并从缓存中提供资源。
我仍然在寻找Chrome的解决方案，因此问题悬而未决。
编辑：即使将Content-Disposition更改为内联后，Chrome也不会对其进行缓存：/