How to efficiently get the expiration date for a Facebook URL and update it before the expiration date?

Question

Main problem:

• Application caches URL from facebook photo CDN
• At some point, the photos end.

My "technical" problem:

• The CDN "expires" Facebook title doesn't seem reliable (or I don’t know how to deal with them).

Using CURL to get the 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?oh=9d34386036754232b79c2208c1075def&oe=54BE4EE2

• One minute before return: Mon, 05 Jan 2015 01:34:28 GMT

• Now it is coming back again: Mon, 05 Jan 2015 01:35:27 GMT

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

Still:

• It seems that one of the most reliable ways is to do background work on checking photos all the time, but this is a little "wrong", for example, "rough forcing".
• The presence of a background job will potentially allow us to allow the expired images to be submitted before this photo clip is “updated”.

My questions:

• Should I use the maximum age parameter even hard, does it seem to not change?
• Is there a reliable way to use facebook CDN url?
• Any other idea on how this should be implemented?
• <joke> Should I use the facebook API to punish badly working encoders? </joke>

Possible solutions?

• Check facebook for last url before showing CDN url

  ~> significantly reduce my requests

• You have a background job updating the url and expiration dates

  ~> would potentially have expired photographs until the work "breaks" them.

• Upload photos to my own CDN

  ~> not a good practice, I would have guessed

UPDATE: ~> Perhaps Tinder actually caches custom images on its own CDN: https://gist.github.com/rtt/10403467 , does Facebook seem to be good with it?

Answer 1

Expires means only one thing, and this is not what you think:

The Expires entity-header field indicates the date / time after which the response is considered obsolete. [...]

The presence of the Expires field does not mean that the original resource will change or cease to exist earlier, before or after this time.

- RFC 2616 §14.21 , emphasis mine

If the URLs of Facebook images stop working after some point in time, this is their business. Their HTTP headers should not mention this, and in fact they do not.

However, I suspect that the URL parameter oe may contain an expiration timestamp. If I interpret 54be4ee2 as a hexadecimal number containing a UNIX timestamp, I get January 20, 2015, which is almost exactly a month later. Perhaps this is the value you are looking for?