2014-12-22 9 views
5

Głównym problemem:Jak skutecznie odzyskać datę wygaśnięcia adresu URL zdjęcia facebooka i odnowić go przed upływem terminu ważności?

  • Zastosowanie buforuje URL z facebook zdjęcie CDN
  • Fotografie wygasa w pewnym momencie

Mój "techniczny" problem:

  • Facebook CDN "wygasa" nagłówek nie wydaje się być niezawodny (lub nie wiem jak sobie z nimi radzić)

Korzystanie CURL aby pobrać datę ważności:

  • 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

  • jedną minutę przed powrócił: Mon, 05 Jan 2015 01:34:28 GMT

  • Wywołanie go ponownie powrócił: Mon, 05 Jan 2015 01:35:27 GMT

  • oba razy " Cache-Control "zwrócone to samo: Cache-Control: max-age=1209600

tej pory:

  • Wydaje się, że jednym z najbardziej niezawodnych sposobów byłoby mieć pracę w tle sprawdzając zdjęciom cały czas, ale że czuje się trochę „źle”, podobnie jak " brutalne forsowanie ".
  • Posiadanie pracy tła potencjalnie umożliwić przeterminowane zdjęcia mają być podawane do chwili to zdjęcie url jest „odnowionego”

moje pytania są następujące:

  • należy używać parametru max-age nawet trudne to się nie zmienia?
  • Czy istnieje wiarygodny sposób używania adresu URL CDN Facebooka?
  • Jakieś inne wyobrażenie o tym, jak powinno to zostać wdrożone?
  • < żart> Czy facebook API powinien być używany do karania źle postępujących koderów? </żart>

Możliwe rozwiązania?

  • Sprawdź facebook dla najnowszego URL przed podaniem jakichkolwiek URL CDN

    ~> spowolni moje prośby dużo

  • mieć pracę tła odnawiającego URL oraz daty ważności

    ~> potencjalnie wygasłoby zdjęcia, gdy praca ich nie "złapie"

  • Pobierz zdjęcia do moim CDN

    ~> nie jest dobrą praktyką i domyśli

UPDATE: ~> Może Krzesiwo rzeczywiście zdjęcia cache użytkownika na własnej CDN: https://gist.github.com/rtt/10403467 więc wydaje się, że Facebook jest niby OK z nim ?

+0

"byłoby mieć pracę w tle, sprawdzając zdjęcia przez cały czas, ale to wydaje się trochę" złe ", jak" brutalne forsowanie "." --- i jeśli pomyślisz przez chwilę, uświadomisz sobie, że Facebook nie wie, kiedy użytkownik modyfikuje swoje zdjęcie, więc nie może podać dokładnej daty wygaśnięcia. Po prostu zakładali, że to 14 dni, które według nich są w porządku. Zrób więc to, co FB każe ci zrobić z nagłówkami HTTP. – zerkms

+0

Oprócz tej hipotezy (użytkownik usuwający zdjęcie), czy uważasz, że powinienem użyć wartości maksymalnego wieku lub daty "Wygasa"? – kroe

+0

Innym poważnym problemem jest to, że czasami jest usuwany przez użytkowników i nie jest usuwany ze swoich CDN - przynajmniej w tym przypadku. – kroe

Odpowiedz

16

Expires oznacza dokładnie jedno, a to nie to, co myślisz, że jest:

Wygasa pole podmiot-header daje datę/czas, po którym reakcja jest uważana nieświeże. [...]

Obecność pola Wygaśnięcie nie oznacza, że ​​oryginalny zasób zmieni się lub przestanie istnieć w, przed lub po tym czasie.

- RFC 2616 §14.21, podkr

Jeśli obraz URL Facebooka przestają działać po pewnym okresie czasu, to ich sprawa. Ich nagłówki HTTP nie muszą o tym wspominać, a tak naprawdę nie.

Z tego powodu, I podejrzewa, że ​​ parametr adresu URL oe może zawierać znacznik czasu wygaśnięcia. Jeśli interpretuję 54be4ee2 jako liczbę szesnastkową zawierającą znacznik czasu UNIX, otrzymam 20 stycznia 2015 r., Czyli prawie dokładnie za miesiąc. Może to wartość, której szukasz?

+0

W rzeczywistości" Wygasa "nie jest zwracane dla wszystkich zdjęć. Sądzę, że powinienem użyć teraz() + maksymalnego wieku? – kroe

+4

Właśnie po to, aby potwierdzić po niektórych testach, które robiłem, parametr oe oznacza, że ​​zdjęcia wygaśnie w systemie szesnastkowym. Dobry połów @ duskwuff –

Powiązane problemy