如何有效地检索Facebook照片URL的到期日期并在到期之前进行更新?

问题描述:

主要问题:

  • 应用程序缓存来自Facebook照片CDN的URL
  • 照片有时会过期

我的技术"问题:

  • Facebook CDN到期"标头似乎不可靠(或者我不知道如何处理)

使用CURL检索到期日期:

Using CURL to retrieve expiration date:

  • curl -i -X HEAD https://scontent-b.xx.fbcdn.net/hphotos-xap1/v/t1.0-9/q82/p320x320/10458607_4654638300864_4316534570262772059_n.jpg?= 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

Both times "Cache-Control" returned the same: Cache-Control: max-age=1209600

到目前为止:

  • 似乎最可靠的方法之一是让后台作业一直检查照片,但这感觉有点错",例如强行用力".
  • 拥有后台工作可能会允许在更新"此照片URL之前提供过期的照片

我的问题是:

  • 我应该使用max-age参数,即使它似乎没有变化也是如此吗?
  • 是否存在使用Facebook的CDN URL的可靠方法?
  • 关于应如何实施的其他任何想法?
  • <笑话> facebook API应该用于惩罚行为不端的编码员吗?</笑话>

可能的解决方案吗?

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

  • Check facebook for the most recent URL before serving any CDN URL

〜>会大大降低我的请求速度

~> would slow down my requests a lot

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

Have a background job renewing the URL and expiration dates

〜>在工作不捕捉"它们的情况下,它们可能已经过期了

~> would potentially have expired photos while the job don't "catch" them

将照片下载到我自己的CDN

Download the photos to my own CDN

〜>我猜不是一个好习惯

~> not a good practice i would guess

更新:〜>也许Tinder实际上将用户的图片缓存在其自己的CDN上: https://gist.github.com/rtt/10403467 ,所以看来Facebook可以接受吗?

UPDATE: ~> Perhaps Tinder actually cache user's pictures on their own CDN: https://gist.github.com/rtt/10403467 so seems like facebook is kind of OK with it?

Expires 完全是一回事,而不是您认为的那样:

Expires means exactly one thing, and it's not what you think it is:

Expires实体标题字段提供了日期/时间,在该日期/时间之后,响应被认为是过期的.[…]

The Expires entity-header field gives the date/time after which the response is considered stale. […]

存在Expires字段并不意味着原始资源将在该时间之前,之后或之后改变或不再存在.

RFC 2616§14.21,重点是我的

如果Facebook的图像URL在某个时间点后停止工作,那就是他们的事.他们的HTTP标头不必提及,实际上也不必.

If Facebook's image URLs stop working after some point in time, that's their business. Their HTTP headers don't have to mention it, and in fact, don't.

话虽这么说,我怀疑 oe URL参数可能包含到期时间戳.如果我将 54be4ee2 解释为包含UNIX时间戳的十六进制数字,则将得到2015年1月20日,这几乎是从现在开始的一个月.可能这就是您想要的价值吗?

That being said, I suspect that the oe URL parameter may contain an expiration timestamp. If I interpret 54be4ee2 as a hexadecimal number containing a UNIX timestamp, I get January 20th, 2015, which is almost exactly a month from now. Might that be the value you're looking for?