Open huluohu opened 8 months ago
一直用的azure存储,还真没考虑过这个问题,蹲一下大佬
个人看法是由于要保证每次访问的链接不一样以保证文件安全,很难在保持这一特性的同时让cdn能够正常缓存,除非增加去除这一防护机制的选项
直接获取直链或许可以缓存,但是这个方案没记错的话也需要302跳一个临时地址再开始下载,需要开启cdn的回源跟踪,这个功能个人没太用过,不确定是否能处理这种情况
我是用的本地存储才会遇到这个问题。 确实,固定下载链接的话跟安全策略又冲突了,头大呀😂
您好,前天尝试通过邮件与你在GitHub主页留有的邮箱取得联系没有收到回复,现将我的想法贴出来:
你好,我是GitHub刚刚回复你的yxzlwz 我有一个猜想,但是由于目前电脑不在身边无法验证,所以先通过邮箱分享下,如果你方便不妨试试 我没记错的话cloudreve分享界面,点击下载文件按钮时,获取临时下载直链的API是固定的。你可以分析一下直链的构造看看直链有效期是多少,然后同时缓存这个固定API的返回和临时直链。如果这样可行的话你可以再进一步试一下把这两项缓存的cdn时间调大到比临时直链有效期更长,由于这两次访问应该在一个cdn节点,如果上面成功,这样之后应该还是可行的。 不知道我有没有说清楚我的想法,期待就这个问题继续联系。
您好,前天尝试通过邮件与你在GitHub主页留有的邮箱取得联系没有收到回复,现将我的想法贴出来:
你好,我是GitHub刚刚回复你的yxzlwz 我有一个猜想,但是由于目前电脑不在身边无法验证,所以先通过邮箱分享下,如果你方便不妨试试 我没记错的话cloudreve分享界面,点击下载文件按钮时,获取临时下载直链的API是固定的。你可以分析一下直链的构造看看直链有效期是多少,然后同时缓存这个固定API的返回和临时直链。如果这样可行的话你可以再进一步试一下把这两项缓存的cdn时间调大到比临时直链有效期更长,由于这两次访问应该在一个cdn节点,如果上面成功,这样之后应该还是可行的。 不知道我有没有说清楚我的想法,期待就这个问题继续联系。
非常感谢指导,我大概理解你说的思路了,我先尝试下看看。
实际测试了下,我是用的是cf的缓存,结果是无效。 原因大概是因为cloudreve获取下载链接API返回的header里面,cache-control设置的是private, no-cache,所以无论怎么设置cf都不会缓存。
暂时不知道其他cdn厂商是不是这种情况。
如题,通过分享链接访问下载页面,点击下载,每次生成的实际下载链接都是不同的,请问这种情况如何配置cdn缓存。
如果不走cdn的话,相当于每次都要回源下载,对服务器上行带宽压力很大。