Dlaczego obrazy z niektórych stron Tumblr nie ładują się, ale działa na nich wget?

Pomagając znajomemu w połączeniu z Internetem, ponieważ „niektóre strony się nie ładują”, zauważyłem, że problem polegał na tym, że obrazy postów graficznych niektórych blogów nie ładowały się w przeglądarce. Uznałem to za dziwne z następujących powodów:

1. Tylko obrazy, które są częścią wpisu, nie zostaną załadowane. Wciąż pojawiają się awatary użytkownika, banery, nagłówki, różne motywy i / lub obrazy związane ze stroną.
2. Zdarza się z każdą przeglądarką na komputerze (Testowane w Firefox i Chrome / ium zarówno z blokadami reklam / skryptów, jak i bez nich).
3. wgetDziała korzystanie z bezpośrednich łączy obrazów.
4. Nie dotyczy to wszystkich stron Tumblr. Większość ładuje się poprawnie, ale podczas tworzenia listy stron zawierających posty, które nie ładują obrazów, widać, że pochodzą one w większości od tej samej grupy użytkowników.
5. Problem wydaje się być specyficzny dla bloga w tym sensie, że jeśli post danego obrazu blogu nie ładuje się w przeglądarce, inne blogi (niezmienione lub nie), które opublikowały ten sam post, nie załadują obrazu również w przeglądarce. I odwrotnie, jeśli blog, którego dotyczy problem, pochodzi od bloga, na który nie ma wpływu, obraz ładuje się dobrze.
6. Obrazy pochodzą z utworzonych przez użytkownika postów Tumblr, gdzie użytkownik przesyła obraz do postu i są hostowane przez Tumblr. Na przykład (przykład ten nie jest jednym z dotkniętych blogów), w tym poście obrazu (losowo wybranego), to byłby bezpośredni link do obrazka w poście. Posty graficzne automatycznie sprawiają, że obrazy są linkiem do innej strony w Tumblr przy użyciu (zwykle) większej wersji obrazu użytego w postie, która jest bliższa rozmiarowi tego, co użytkownik przesłał dla posta.

Co może być przyczyną takiego zdarzenia? To, co mnie naprawdę łapie, to fakt, że wgetdziała, więc myślę, że mogę założyć, że to nie jest problem z połączeniem sieciowym.

Aktualizacja:

Oto przykład posta w trybie offline, który nie ładuje się w przeglądarkach. Główny blog ma inne posty obrazu, które ładują się prawidłowo. To jest bezpośredni link do obrazu w poście i tutaj jest ten dla większej wersji (oba nie ładują się tutaj). wgetdziała w obu przypadkach, ale po przejściu do dowolnego bezpośredniego łącza z Firefoksem pojawia się ten błąd:

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<Error>
    <Code>AccessDenied</Code>
    <Message>Access Denied</Message>
    <RequestId>A626307DF577B411</RequestId>
    <HostId>J9GxX1HY9vX3ElWjYf7M48ByvKXLRIwRBJ2al2voS3J/C+WhILWHyd3crFhhNtkXuvG0zaxBTxw=</HostId>
</Error>

RequestIDi HostIdzmienia się za każdym razem. Mój przyjaciel i ja mieszkamy na Filipinach.

Aktualizacja [2014/03/08]

Po dalszych testach i odpowiadaniu na wiadomości e-mail pomocy technicznej Tumblr, wgetw niektórych przypadkach przestał działać (pojawia się błąd 403 w bezpośrednich linkach).

Aktualizacja [2014/03/09]

Wyłączenie reguł Tumblr dla HTTPS-Everywhere wydaje się czasem rozwiązać problem.

_Uwaga:

• _{W przykładzie dla # 6 oba bezpośrednie łącza wskazują ten sam obraz. Zazwyczaj jednak ten użyty w poście z obrazem (w porównaniu do strony z obrazem z możliwością powiększania) używa mniejszej wersji obrazu, aby pasował do motywu strony. W przykładzie użyto motywu przeznaczonego dla większych ekranów, więc nie potrzebuje mniejszej wersji.}

AKTUALIZACJA: Wydaje się, że podstawowy problem z brakiem ładowania obrazów wynikał ze sposobu, w jaki wtyczka / rozszerzenie EFF HTTPS Everywhere obsługiwała niektóre adresy URL Tumblr. Deweloper został powiadomiony i wydaje się, że wprowadzono poprawkę . Ta odpowiedź zasadniczo dzieli pracę detektywa wykonaną w celu wykrycia problemu, jak wskazano w początkowym pytaniu, i może okazać się przydatna do dalszego debugowania / diagnozy, jeśli podobny problem pojawi się w przyszłości.

EDYCJA: Większa treść na temat pijawki obrazu wydaje się nieprawidłowa. Tak więc doda nowy pomysł na górze i pozostawi informacje o wysysaniu obrazu na dole, na wypadek, gdyby komuś się przydał.

Pomysły Amazon CloudFront CDN

Okej, używając podanych przez ciebie adresów URL - a także niektórych moich rzeczywistych doświadczeń z konfiguracjami Amazon CloudFront CDN - myślę, że coś odkryłem. Wygląda na to, że konfiguracja CDN Amazon CloudFront firmy Tumblr dusi się z jakiegoś powodu. Oto dlaczego tak myślę.

Weźmy ten przykładowy adres URL:

http://36.media.tumblr.com/d685b02fdf2d3f167c22d9a97e27e87a/tumblr_nfpq5qPZ4v1tognpro1_1280.png

Teraz uruchommy, curl -Iaby uzyskać informacje o nagłówku tego pliku:

curl -I http://36.media.tumblr.com/d685b02fdf2d3f167c22d9a97e27e87a/tumblr_nfpq5qPZ4v1tognpro1_1280.png

Wynik tego byłby mniej więcej taki:

HTTP/1.1 200 OK
Content-Type: image/png
Content-Length: 782141
Connection: keep-alive
Accept-Ranges: bytes
Cache-Control: max-age=1209600
Date: Thu, 05 Mar 2015 02:15:44 GMT
Server: nginx
X-Cache: Miss from cloudfront
Via: 1.1 7e54fc06cd70e4752fe050bbe5c130be.cloudfront.net (CloudFront)
X-Amz-Cf-Id: QyIUyzfaJJN3PU_xWkW0P-D2kjg_1cVenKzFAoY2PubgZQlBHWorZQ==

Teraz należy zwrócić uwagę na Date(datę i godzinę pliku w punkcie końcowym CloudFront) oraz X-Cache(nagłówki stanu dostarczania treści Amazon). Typowe zachowanie na Amazon CloudFront polega na tym, że pierwszy dostęp przekazuje komunikat „Miss from cloudfront”, a następnie, jeśli zrobisz kolejne curl -Iod razu, powinno być Hit from cloudfront.

Ale nie to właśnie widziałem. Oto zestawienie Datei X-Cachestatus wielu dostępów, które wykonałem:

• Date: Thu, 05 Mar 2015 02:19:37 GMT = X-Cache: Miss from cloudfront
• Date: Thu, 05 Mar 2015 02:19:39 GMT = X-Cache: Miss from cloudfront
• Date: Thu, 05 Mar 2015 02:19:44 GMT = X-Cache: Miss from cloudfront
• Date: Thu, 05 Mar 2015 02:19:50 GMT = X-Cache: Miss from cloudfront
• Date: Thu, 05 Mar 2015 02:19:50 GMT = X-Cache: Hit from cloudfront
• Date: Thu, 05 Mar 2015 02:19:50 GMT = X-Cache: Hit from cloudfront
• Date: Thu, 05 Mar 2015 02:19:50 GMT = X-Cache: Hit from cloudfront

Powodem, dla którego istnieje wiele elementów z tymi samymi dokładnymi danymi, które są Hit from cloudfrontblisko końca, jest to, co dzieje się w CDN: Jeśli punkt końcowy CDN ma plik, to Datekoreluje z faktyczną datą utworzenia / modyfikacji pliku, który punkt końcowy ma.

Zauważysz, że pierwsze cztery dostęp są w odstępie kilku sekund, z różnymi datami / godzinami i wszystkie są Miss from cloudfront, prawda? Oznacza to, że punkt końcowy CDN po prostu przypomina, że ​​w tamtych czasach próbowano uzyskać dostęp do tego pliku i wszystkie próby zakończyły się niepowodzeniem.

Więc moja ocena tego fotela jest taka, że ​​systemy Tumblr nie nadążają za Amazon CloudFront CDN lub Amazon CloudFront CDN nie nadąża za Tumblr. Ale w pewnym sensie po stronie serwera wszystko jest nie tak. A ponieważ jest to CDN, ktoś uzyskujący dostęp do plików w jednej lokalizacji może nie zauważyć problemu, podczas gdy ktoś w innej lokalizacji miałby problemy z wyświetlaniem obrazu.

To znaczy, nie sądzę, że można to łatwo wyjaśnić po stronie klienta.

EDYCJA: Więc oryginalny plakat dodał kilka nowych adresów URL, a to wciąż wskazuje na problem po stronie serwera, ale chciałem tylko opublikować szczegóły dotyczące rekordu.

EdgeCast & Highwinds CDN Ideas

Więc oryginalny plakat dodał więcej szczegółów, więc oto więcej szczegółów na podstawie postu na blogu, który jest użyty jako przykład:

http://claystorks.tumblr.com/post/112741831192/soulmister-claystorks-windspeare-explain

Te adresy URL obrazów są podane jako przykłady adresów URL w tym poście:

https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_500.png

https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_1280.png

I te dwa adresy URL obrazów faktycznie zawodzą. Ale z mojej strony - patrząc na oryginalny kod Soure posta na blogu z Brooklynu, Nowy Jork, USA - nie widzę tych gs1.wac.edgecastcdn.netadresów URL EdgeCast ( ). Są to raczej adresy URL, które widzę:

http://41.media.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_500.png

http://41.media.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_1280.png

Tak więc moją pierwszą myślą jest to, dlaczego oryginalny plakat widzi te EdgeCast ( gs1.wac.edgecastcdn.net). Ale jeśli zrobię 41.media.tumblr.comśledzenie trasy do , zobaczę, że jest to serwer zarządzany przez Highwinds (!?!?). Natomiast początkowe adresy URL przekazywane przez pierwotnego użytkownika używają 36.media.tumblr.comnazwy hosta i widać, że są zarządzane przez serwery Amazon CloudFront CDN.

To wszystko, co muszę powiedzieć - co powiedziałem wcześniej - wydaje się, że jest to problem po stronie serwera w Tumblr i zarządzaniu CDN. Ale z mojej strony - na Brooklynie w Nowym Jorku, USA - wyraźnie widzę, że treści są dostarczane zgodnie z oczekiwaniami z serwerów CDN Highwinds oraz serwerów CDN Amazon CloudFront. Skąd pochodzą te adresy URL EdgeCast lub jak / dlaczego się nie udaje, nie ma żadnej kontroli po stronie klienta. To zdecydowanie byłoby coś do skontaktowania się z personelem technicznym Tumblr, ponieważ nie ma sposobu, aby użytkownik końcowy mógł rozwiązać ten problem.

Pomysły na pijawki

To może nie być już istotne, ale tutaj w celach informacyjnych.

Mówiąc to, daj mi wskazówkę:

wgetDziała korzystanie z bezpośrednich łączy obrazów.

W wielu witrynach obowiązują reguły - zwykle ustawiane za pomocą Apache - które zapobiegają wysysaniu obrazu. Więcej szczegółów na temat działania tych reguł można znaleźć tutaj i podsumowano w następujący sposób:

Korzystając z .htaccess, możesz zabronić łączenia na gorąco na swoim serwerze, więc osoby próbujące na przykład połączyć się z obrazem lub plikiem CSS w Twojej witrynie, albo zostaną zablokowane (nieudane żądanie, takie jak uszkodzony obraz), albo podadzą inną treść ( tj. obraz gniewnego mężczyzny).

Na podstawie twojego opisu - oraz faktu, że możesz uzyskać dostęp do obrazów za pośrednictwem - wgetprowadzi mnie do przekonania, że ​​obrazy, z którymi masz problemy, nie są hostowane w Tumblr przez użytkowników, ale raczej obrazy, które są umieszczone na blogu Tumblr, ale faktycznie są hostowane na innym teren.

Po wdrożeniu standardowych procedur ługowania obrazu wyświetlenie obrazu osadzonego w jednej witrynie hostowanej w innej witrynie - która blokuje pijawkę - spowoduje uszkodzenie łącza do obrazu lub „Stop Leeching!” obraz jest zwracany. Wynika to z faktu, że podstawowe reguły anty-pijawkowe - takie jak na tej przykładowej stronie - sprawdzają odwołania do obrazków, aby upewnić się, że strona żądająca obrazu pasuje do domeny, na której znajduje się obraz.

Więc kiedy uzyskujesz dostęp do obrazu za pośrednictwem, wgetmasz bezpośredni dostęp do obrazu. Tak więc reguły wysysania obrazu nie uruchomiłyby się. W ten sposób można uzyskać obraz, wgetale nie wtedy, gdy jest on osadzony na innej stronie.

Mam obecnie ten bardzo problem. Jest to bezpieczny do pracy - cóż, to głupiutki komiks - przykład bloga, którego dotyczy problem .

Jeśli jednak okaże się, że problem wystąpił tylko w Chrome dla mnie. Po chwili zdałem sobie sprawę, że przyczyną problemu było rozszerzenie „ HTTPS Everywhere ”. Kiedy zainstalowałem go w Firefoksie, miałem tam ten sam problem. I właściwie, jeśli wyłączę regułę HTTPS „Tumblr (częściowe)” (co, jak sądzę, oznacza *.tumblr.com), to znowu działa dobrze.

Problem polega na tym, że przynajmniej czasami , gdy HTTPS jest używany do uzyskania dostępu do obrazu, następuje przekierowanie do nieprawidłowego adresu URL EdgeCast. Na przykład ten adres URL obrazu działa dobrze:

http://36.media.tumblr.com/57d2af15f7b21037364125f9f32c4379/tumblr_nktjzyNkv91s667kio1_1280.png

Ale jeśli zmienisz protokół z httpna https, zostaniesz przekierowany na ten adres URL, który nie działa:

https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/57d2af15f7b21037364125f9f32c4379/tumblr_nktjzyNkv91s667kio1_1280.png

Nie jestem pewien, czy liczy się to jako błąd ze strony Tumblr, czy nie. Myślę, że jeśli klienci nie powinni uzyskiwać dostępu do swoich serwerów multimediów za pomocą HTTPS, nie można ich za to winić.

EDYCJA: I rzeczywiście problem został rozwiązany, jak opisano w tym wątku GitHub .

Zauważyłem to bardziej, gdy korzystałem z usług mojego operatora komórkowego, T-Mobile. Myślę, że jest to pewnego rodzaju kształtowanie ruchu na podstawie rozmiaru obrazu lub jakiegoś „wskaźnika trudności” zbudowanego przez przewoźnika przy wycofywaniu wspomnianego elementu.

W poprzednich testach - ponad rok temu - udostępniłem zepsuty post znajomemu, który ma Verizon, a obraz ładuje się dobrze.

Chociaż nie mogę przetestować tego obrazu, który zamierzam dostarczyć - ponieważ mój przyjaciel jest niedostępny - ten obraz nie ładuje się dla mnie. Używam standardowego Androida (5.0.1) na Nexusie 5, używając przeglądarki Chrome jako przeglądarki.

http://41.media.tumblr.com/efebad51567e927b8f130f9bdc4efae3/tumblr_ndvnpjcBZa1qewacoo1_500.png

Gdy próbuję załadować obraz bezpośrednio, pojawia się błąd przekroczenia limitu czasu bramy 504.

EDYCJA: To jest @JakeGould publikujący rzeczywisty obraz w celach informacyjnych.

Dalsze testy i szczegóły: Jestem w Baltimore MD, brak danych LTE i następujący obraz działał: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

Dalsze testy pokazują, że PNG nie wydaje się być problemem. Większość innych obrazów, które trafiłem, które działały, były mieszanką png i jpg, ale wszystkie były na serwerach innych niż „41”.

Ostatnia uwaga: wróciłem do domu, wskoczyłem na moją sieć Wi-Fi - z moim telefonem - urządzeniem, na którym testowałem - i wszystkimi zdjęciami, których nie widziałem z powodu 504, które teraz widzę.

EDYCJA: Nowy dla superużytkownika, przycięty i zredagowany post, więc był bardziej oparty na faktach i mniej dyskusji.

AKTUALIZACJA: Wydaje się, że problem jest związany z LTE. Załadowałem tumblr, znalazłem kilka zdjęć, które się nie ładowały, zmusiłem mój telefon do 3g, ponownie załadowałem stronę, wszystkie obrazy pokazują. Przywróciłem telefon z powrotem do LTE, wyczyściłem pamięć podręczną, a obrazy, które wcześniej nie ładowały się pod LTE, teraz ładują się.
(Testuję ponownie i teraz nie mogę się rozmnażać. Więc może powyższe zachowanie było fartem.)