主要问题:
应用程序从Facebook照片CDN缓存URL
照片会在某个时候到期
我的"技术"问题:
Facebook CDN"过期"标题似乎不可靠(或者我不知道如何处理它们)
使用CURL检索到期日期:
curl -i -X HEAD https://scontent-b.xx.fbcdn.net/hphotos-xap1/v/t1.0-9/q82/p320x320/10458607_4654638300864_4316534570262772059_n.jpg?oh=9d34386036754232b79c2208c1075def&oe=54BE4EE2
返回前一分钟: Mon, 05 Jan 2015 01:34:28 GMT
现在再次调用它返回: Mon, 05 Jan 2015 01:35:27 GMT
两次"Cache-Control"都返回相同的内容: Cache-Control: max-age=1209600
至今:
看起来最可靠的方法之一就是让背景工作一直检查照片,但感觉有点"错误",比如"暴力强迫".
有一个后台工作可能会允许过期的图片提供到这个照片网址"更新"的那一刻
我的问题是:
我应该使用max-age参数,即使是艰难的,它似乎也没有改变?
有没有可靠的方式使用Facebook的CDN URL?
关于如何实现这一点的任何其他想法?
<笑话>应该使用facebook API来惩罚行为不端的程序员吗? joke>
可能的解决方案 ?
在提供任何CDN URL之前,请检查Facebook以获取最新的URL
〜>会慢慢减慢我的要求
有后台工作续订URL和到期日期
〜>当工作没有"抓住"它们时,可能会有过期的照片
将照片下载到我自己的CDN
〜>不是我猜的好习惯
更新:〜>也许Tinder实际上将用户的图片缓存在他们自己的CDN上:https://gist.github.com/rtt/10403467所以看起来facebook有点好吗?
Expires
完全是一件事,而不是你的想法:
Expires entity-header字段给出了响应被视为过时的日期/时间.[...]
Expires字段的存在并不意味着原始资源将在该时间之前,之前或之后改变或停止存在.
- RFC2616§14.21,强调我的
如果Facebook的图像URL在某个时间点后停止工作,那就是他们的业务.他们的HTTP标头不必提及它,事实上,不必提及它.
话虽这么说,我怀疑的是,oe
URL参数可能包含过期时间戳.如果我将其解释54be4ee2
为包含UNIX时间戳的十六进制数字,那么我将从2015年1月20日开始,这几乎就是从现在开始的一个月.可能是您正在寻找的价值?