如何有效地检索 Facebook 照片 URL 的到期日期并在到期前续订？

主要问题：

• 应用程序缓存来自 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

So far:

• 似乎最可靠的方法之一是让后台工作一直检查照片，但这感觉有点“错误”，就像“暴力破解”。
• 拥有后台作业可能会允许在该照片网址“更新”之前提供过期的图片

我的问题是：

• 即使 max-age 参数似乎没有改变，我是否应该使用它？
• 有没有可靠的方法来使用 facebook 的 CDN URL？
• 关于如何实施还有其他想法吗？
• Facebook API应该用来惩罚行为恶劣的程序员吗？笑话>

可能的解决方案 ？

• 在提供任何 CDN URL 之前，请检查 facebook 是否有最新的 URL

  ~> 会大大减慢我的请求速度

• 有一个后台作业来更新 URL 和到期日期

  ~> 可能会有过期的照片，而工作不会“捕获”它们

• 将照片下载到我自己的 CDN

  〜>我猜这不是一个好习惯

更新： ~> 也许 Tinder 实际上将用户的图片缓存在自己的 CDN 上：https://gist.github.com/rtt/10403467看来 Facebook 对此还算满意吧？

Expires确切地说是一件事，但它不是你想象的那样：

Expires 实体标头字段给出了响应被视为过时的日期/时间。 […]

Expires 字段的存在并不意味着原始资源将在该时间、之前或之后发生更改或不再存在。

— RFC 2616 §14.21，强调我的

如果 Facebook 的图片 URL 在某个时间点后停止工作，那是他们的事。他们的 HTTP 标头不必提及它，事实上也没有提及。

话虽这么说，我suspect那oeURL 参数可能包含过期时间戳。如果我解释54be4ee2作为包含 UNIX 时间戳的十六进制数字，我得到的是 2015 年 1 月 20 日，距离现在几乎正好一个月。这可能就是您正在寻找的价值吗？