Warum werden Bilder von einigen Tumblr-Seiten nicht geladen, aber die Verwendung von wget funktioniert?

Als ich einem Freund bei seiner Internetverbindung half, weil „einige Seiten nicht geladen werden“, bemerkte ich, dass das Problem darin bestand, dass die Bilder der Bildbeiträge bestimmter Blogs nicht in den Browser geladen wurden. Ich fand es aus folgenden Gründen seltsam:

1. Nur Bilder, die Teil des Beitrags sind, werden nicht geladen. Benutzeravatare, Banner, Überschriften, verschiedene themenbezogene und / oder seitenbezogene Bilder werden weiterhin angezeigt.
2. Passiert mit jedem Browser auf dem Computer (Getestet unter Firefox und Chrome / ium mit und ohne Werbe- / Skriptblocker).
3. Die Verwendung wgetder direkten Links der Bilder funktioniert.
4. Dies gilt nicht für alle Tumblr-Seiten. Die meisten werden ordnungsgemäß geladen, aber wenn Sie eine Liste von Seiten mit Posts erstellen, in denen keine Bilder geladen werden, zeigen Sie, dass sie größtenteils von derselben Gruppe von Benutzern stammen.
5. Das Problem scheint in dem Sinne blogspezifisch zu sein, dass andere Blogs (nicht betroffen oder nicht), die denselben Beitrag erstellt haben, das Bild auch nicht in den Browser laden, wenn der Bildbeitrag eines bestimmten Blogs nicht in den Browser geladen wird. Wenn es sich bei einem betroffenen Blog hingegen um ein nicht betroffenes Blog handelt, wird das Bild problemlos geladen.
6. Die Bilder stammen aus vom Benutzer erstellten Tumblr-Posts, in denen der Benutzer ein Bild zum Posten hochlädt, und werden von Tumblr gehostet. Zum Beispiel ( in diesem Beispiel nicht einer des betroffenen Blogs ist), in diesem Bild Post (zufällig ausgewählt), dies würde die direkte Verbindung in der Post zu dem Bild sein. Bildbeiträge machen die Bilder automatisch zu einem Link zu einer anderen Seite in Tumblr, wobei eine (normalerweise) größere Version des in dem Beitrag verwendeten Bildes verwendet wird, die näher an der Größe liegt, die der Benutzer für den Beitrag hochgeladen hat.

Was kann möglicherweise der Grund dafür sein? Der Teil, der mich wirklich erwischt, ist die Tatsache, dass es wgetfunktioniert, also kann ich davon ausgehen, dass es kein Problem mit der Netzwerkverbindung ist.

Aktualisieren:

Hier ist ein Beispiel für einen umrundeten Beitrag, der nicht in die Browser geladen werden kann. Der Hauptblog enthält andere Bildbeiträge, die ordnungsgemäß geladen werden. Dies ist der direkte Link zum Bild im Beitrag und hier ist der für die größere Version (beide werden hier nicht geladen). wgetfunktioniert für beide, aber wenn Sie zu einer direkten Verbindung mit Firefox gehen, wird dieser Fehler angezeigt:

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>

RequestIDund HostIdändert sich jedes Mal. Mein Freund und ich befinden uns auf den Philippinen.

Update [08.03.2014]

Bei weiteren Tests und Antworten auf die E-Mails des Tumblr-Supports wgetfunktioniert es gelegentlich nicht mehr (403 Fehler bei direkten Links).

Update [2014/03/09]

Das Deaktivieren der Tumblr-Regeln für HTTPS-Everywhere scheint das Problem manchmal zu beheben.

_Hinweis:

• _{Im Beispiel für # 6 verweisen direkte Links beide auf dasselbe Bild. Normalerweise verwendet die im Bildbeitrag verwendete (im Vergleich zur zoombaren Bildseite) jedoch eine kleinere Version des Bildes, um dem Thema der Seite zu entsprechen. In diesem Beispiel wird ein Thema für größere Bildschirme verwendet, sodass die kleinere Version nicht benötigt wird.}

UPDATE: Es scheint, dass das Hauptproblem bei Bildern, die nicht geladen werden, auf die Art und Weise zurückzuführen ist, wie das HTTPS Everywhere-Plugin / die Erweiterung des EFF einige Tumblr-URLs verarbeitet hat. Die Entwickler wurden benachrichtigt und ein Fix scheint vorhanden zu sein . Diese Antwort bricht im Wesentlichen die Detektivarbeit auf, die durchgeführt wurde, um das Problem aufzudecken, wie in der ursprünglichen Frage dargelegt, und könnte sich für das weitere Debuggen / Diagnostizieren als nützlich erweisen, wenn in Zukunft ein ähnliches Problem auftritt.

BEARBEITEN: Der größere Inhalt über Bild-Blutegel scheint ungültig zu sein. Fügen Sie also oben eine neue Idee hinzu und lassen Sie die Bild-Leeching-Informationen unten, nur für den Fall, dass sie für jemanden nützlich sind.

Amazon CloudFront CDN-Ideen

Okay, unter Verwendung der von Ihnen angegebenen URLs sowie einiger meiner Erfahrungen aus der Praxis mit Amazon CloudFront CDN-Setups habe ich etwas entdeckt. Es scheint, als ob die Amazon CloudFront CDN-Konfiguration von Tumblr aus irgendeinem Grund erstickt. Deshalb denke ich, dass dies der Fall ist.

Nehmen wir diese Beispiel-URL:

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

Lassen Sie uns nun ausführen curl -I, um Header-Informationen zu dieser Datei abzurufen:

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

Die Ausgabe dafür wäre ungefähr so:

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==

Hier sind die Header Date(Datum und Uhrzeit der Datei auf dem CloudFront-Endpunkt) und X-Cache(Status der Bereitstellung von Amazon-Inhalten) zu beachten. Ein typisches Verhalten bei Amazon CloudFront ist, dass beim ersten Zugriff ein "Miss from Cloudfront" angezeigt wird. Wenn Sie curl -Idanach sofort einen anderen ausführen, sollte ein Fehler auftreten Hit from cloudfront.

Aber das habe ich gerade nicht gesehen. Hier ist eine Aufschlüsselung des Dateund X-CacheStatus eines Bündels von Zugriffen mir gemacht:

• 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

Der Grund, warum es mehrere Elemente mit denselben genauen Daten gibt, die sich Hit from cloudfrontdem Ende nähern, liegt darin, dass dies auf einem CDN geschieht: Wenn der Endpunkt des CDN über die Datei verfügt, Datekorreliert dies mit dem tatsächlichen Erstellungs- / Änderungsdatum der Datei, die Endpunkt hat.

Sie bemerken, dass die ersten vier Zugriffe Sekunden voneinander entfernt sind, mit unterschiedlichen Daten / Zeiten und alle Miss from cloudfront, oder? Das bedeutet, dass der CDN-Endpunkt nur wiederholt, dass zu diesem Zeitpunkt versucht wurde, auf diese Datei zuzugreifen, und dass alle Versuche fehlgeschlagen sind.

Meine Einschätzung dazu ist, dass die Systeme von Tumblr nicht mit dem Amazon CloudFront CDN mithalten oder das Amazon CloudFront CDN nicht mit Tumblr mithalten kann. Aber in gewisser Weise sind die Dinge auf ihrer Serverseite nicht in Ordnung. Und da dies ein CDN ist, bemerkt jemand, der an einem Ort auf die Dateien zugreift, möglicherweise kein Problem, während jemand anderes an einem anderen Ort Probleme beim Anzeigen des Bildes hat.

Was alles zu sagen ist, ich denke nicht, dass dies auf der Client-Seite leicht geklärt werden kann.

BEARBEITEN: Das ursprüngliche Poster hat also einige neue URLs hinzugefügt, und dies weist immer noch auf ein serverseitiges Problem hin, aber ich wollte nur die Details für den Datensatz veröffentlichen.

EdgeCast & Highwinds CDN-Ideen

Das Originalposter hat also weitere Details hinzugefügt. Hier sind weitere Details basierend auf dem Blog-Beitrag, der als Beispiel verwendet wird:

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

Diese Bild-URLs werden als Beispiele für URLs in diesem Beitrag bereitgestellt:

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

Und diese beiden Bild-URLs schlagen tatsächlich fehl. Aber von meiner Seite aus - wenn ich mir den ursprünglichen Soure-Code des Blogposts aus Brooklyn, New York, USA ansehe - sehe ich diese EdgeCast ( gs1.wac.edgecastcdn.net) - URLs nicht. Dies sind vielmehr die URLs, die ich sehe:

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

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

Mein erster Gedanke ist also, warum das Originalposter diese EdgeCast ( gs1.wac.edgecastcdn.net) sieht . Aber wenn ich dann eine Traceroute zum mache, 41.media.tumblr.comsehe ich, dass dies ein Server ist, der von Highwinds verwaltet wird (!?!?). Im Gegensatz dazu verwenden die vom ursprünglichen Benutzer weitergegebenen ursprünglichen URLs den 36.media.tumblr.comHostnamen, und Sie können sehen, dass sie von Amazon CloudFront CDN-Servern verwaltet werden.

Was alles zu sagen ist - was ich bereits gesagt habe - all dies scheint ein serverseitiges Problem mit Tumblr und dessen CDN-Verwaltung zu sein. Aber von meiner Seite - in Brooklyn, New York, USA - sehe ich deutlich, dass Inhalte wie erwartet von Highwinds CDN-Servern sowie von Amazon CloudFront CDN-Servern geliefert werden. Woher diese EdgeCast-URLs kommen oder wie / warum sie dann fehlschlagen, kann der Client nicht kontrollieren. Dies ist definitiv eine Kontaktaufnahme mit den technischen Mitarbeitern von Tumblr, da ein Desktop-Endbenutzer dies auf keinen Fall beheben kann.

Image Leeching Ideen

Könnte nicht mehr relevant sein, aber hier als Referenz.

Wenn Sie dies angeben, geben Sie mir einen Hinweis:

Die Verwendung wgetder direkten Links der Bilder funktioniert.

Auf vielen Websites gibt es Regeln, die normalerweise über Apache festgelegt werden und die das Löschen von Bildern verhindern. Weitere Einzelheiten zur Funktionsweise dieser Regeln finden Sie hier und werden wie folgt zusammengefasst:

Mit .htaccess können Sie Hotlinks auf Ihrem Server nicht zulassen, sodass diejenigen, die beispielsweise versuchen, eine Verknüpfung zu einem Bild oder einer CSS-Datei auf Ihrer Site herzustellen, entweder blockiert werden (fehlgeschlagene Anforderung, z. B. ein fehlerhaftes Bild) oder einen anderen Inhalt bereitstellen ( dh: ein Bild eines wütenden Mannes).

Aufgrund Ihrer Beschreibung - und der Tatsache, dass Sie über auf die Bilder zugreifen können - wgetkann ich davon ausgehen, dass die Bilder, mit denen Sie Probleme haben, nicht von Benutzern auf Tumblr gehostet werden, sondern von Bildern, die in einem Tumblr-Blog platziert, aber tatsächlich auf einem anderen gehostet werden Seite? ˅.

Wenn Standardverfahren zum Löschen von Bildern eingeführt werden, führt das Anzeigen eines eingebetteten Bildes auf einer Site, die auf einer anderen Site gehostet wird - was das Leeching blockiert - zu einer fehlerhaften Bildverknüpfung oder möglicherweise zu einem „Stop Leeching!“. Bild wird zurückgegeben. Dies liegt daran, dass grundlegende Anti-Blutegel-Regeln - wie die auf dieser Beispielseite - Bildverweise überprüfen, um sicherzustellen, dass die Seite, auf der das Bild angefordert wird, mit der Domäne übereinstimmt, in der sich das Bild befindet.

Wenn Sie also über auf das Bild zugreifen wget, greifen Sie direkt auf das Bild zu. Die Regeln für das Ausbluten von Bildern würden also nicht in Kraft treten. Sie können das Bild also über, wgetaber nicht erhalten, wenn es in eine andere Seite eingebettet ist.

Ich habe gerade genau dieses Problem. Dies ist ein sicherer Arbeitsplatz - nun, es ist ein alberner Comic - ein Beispiel für ein betroffenes Blog .

Wenn jedoch festgestellt wird, dass das Problem nur in Chrome für mich aufgetreten ist. Nach einer Weile wurde mir klar, dass die Ursache des Problems die Erweiterung " HTTPS Everywhere " war. Als ich es in Firefox installiert habe, hatte ich auch dort das gleiche Problem. Und tatsächlich, wenn ich die HTTPS-Regel "Tumblr (teilweise)" deaktiviere (was ich denke, bedeutet *.tumblr.com), funktioniert es wieder gut.

Das Problem scheint also zu sein, dass Sie zumindest manchmal , wenn HTTPS für den Zugriff auf ein Bild verwendet wird, zu einer ungültigen EdgeCast-URL umgeleitet werden. Diese Bild-URL funktioniert beispielsweise einwandfrei:

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

Wenn Sie jedoch das Protokoll von httpauf ändern , werden httpsSie zu dieser URL weitergeleitet, die nicht funktioniert:

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

Ich bin mir nicht sicher, ob dies als Fehler von Tumblr-Seite gilt oder nicht. Ich denke, wenn Clients nicht mit HTTPS auf ihre Medienserver zugreifen sollen, können Sie sie nicht wirklich dafür verantwortlich machen.

EDIT: Und tatsächlich scheint das Problem wie in diesem GitHub-Thread beschrieben behandelt worden zu sein .

Ich habe dieses Verhalten auf meinem Mobilfunkanbieter T-Mobile häufiger bemerkt. Ich denke, dies ist eine Art von Traffic-Shaping, das auf der Bildgröße basiert, oder eine von einem Carrier erstellte „Schwierigkeitsmetrik“, mit der das Element erneut abgerufen werden kann.

In früheren Tests - vor über einem Jahr - habe ich den fehlerhaften Beitrag dann an einen Freund mit Verizon weitergegeben, und das Bild wird einwandfrei geladen.

Obwohl ich dieses Bild, das ich bereitstellen werde, nicht testen kann, da mein Freund nicht verfügbar ist, wird dieses Bild für mich nicht geladen. Ich verwende Stock Android (5.0.1) auf einem Nexus 5 mit Chrome als Browser.

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

Wenn ich versuche, das Image direkt zu laden, wird ein Timeout-Fehler für das 504-Gateway angezeigt.

BEARBEITEN : Dies ist @JakeGould, das das tatsächliche Bild als Referenz veröffentlicht.

Weitere Tests und Details: Ich bin in Baltimore, MD, habe keine LTE-Daten mehr und das folgende Bild hat funktioniert: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

Weitere Tests zeigen, dass PNG nicht das Problem zu sein scheint. Die meisten anderen Bilder, die ich getroffen habe, waren eine Mischung aus PNG und JPG, aber alle befanden sich auf Servern, die nicht "41" waren.

Schlussbemerkung: Ich bin nach Hause gekommen und habe mit meinem Telefon - dem Gerät, auf dem ich getestet habe - und meinem Foto, das ich aufgrund von 504 nicht sehen konnte, mein WLAN - Comcast - genutzt.

BEARBEITEN: Neu bei Superuser, gekürzter und bearbeiteter Beitrag, damit er sachlicher und weniger diskutiert wurde.

UPDATE: Das Problem scheint mit LTE verbunden zu sein. Tumblr geladen, einige Bilder gefunden, die nicht geladen werden konnten, mein Handy auf 3g heruntergedrückt, Seite neu geladen, alle Bilder zeigen. Das Telefon wurde auf LTE zurückgesetzt, der Cache geleert und die Bilder, die zuvor nicht unter LTE geladen wurden, werden jetzt geladen.
(Ich teste erneut und jetzt kann ich nicht reproduzieren. Vielleicht war das obige Verhalten ein Zufall.)