Pourquoi les images de certaines pages Tumblr ne se chargent-elles pas, mais utiliser wget sur celles-ci fonctionne?

En aidant un ami avec sa connexion Internet car «certaines pages ne se chargent pas», j'ai remarqué que le problème était que les images des publications d'images de certains blogs n'étaient pas chargées sur le navigateur. Je l'ai trouvé bizarre pour les raisons suivantes:

1. Seules les images faisant partie de la publication ne seront pas chargées. Les avatars des utilisateurs, les bannières, les en-têtes, les différentes images de thème et / ou de page apparaissent toujours.
2. Se produit avec n'importe quel navigateur sur l'ordinateur (testé sur Firefox et Chrome / ium avec et sans bloqueurs de publicités / scripts).
3. L'utilisation wgetdes liens directs des images fonctionne.
4. Cela ne s'applique pas à toutes les pages Tumblr. La plupart se chargent correctement, mais lorsque vous créez une liste de pages avec des publications qui ne chargent pas d'images, montrez qu'elles proviennent principalement du même groupe d'utilisateurs.
5. Le problème semble être spécifique au blog dans le sens où si une publication d'image d'un blog ne se charge pas dans le navigateur, les autres blogs (non affectés ou non) qui ont publié la même publication ne chargeront pas non plus l'image dans le navigateur. Inversement, si un blog affecté est renvoyé à partir d'un blog non affecté, l'image se charge correctement.
6. Les images proviennent de publications Tumblr créées par l'utilisateur où l'utilisateur télécharge une image à publier et sont hébergées par Tumblr. Par exemple (cet exemple ne fait pas partie des blogs concernés), dans cette publication d'image (sélectionnée au hasard), ce serait le lien direct vers l'image dans la publication. Les publications d'image font automatiquement des images un lien vers une autre page dans Tumblr en utilisant une version (généralement) plus grande de l'image utilisée dans la publication qui est plus proche de la taille de ce que l'utilisateur a téléchargé pour la publication.

Quelle peut être la raison de ce phénomène? La partie qui m'attire vraiment est le fait que cela wgetfonctionne, donc je pense que je peux supposer que ce n'est pas un problème avec la connexion réseau.

Mise à jour:

Voici un exemple de message posté qui ne parvient pas à se charger sur les navigateurs. Le blog principal contient d'autres publications d'image qui se chargent correctement. Ceci est le lien direct vers l'image dans le message et voici celui de la version plus grande (les deux ne se chargent pas ici). wgetfonctionne pour les deux, mais en allant sur n'importe quel lien direct avec Firefox, cette erreur apparaît:

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>

RequestIDet HostIdchange à chaque fois. Mon ami et moi sommes situés aux Philippines.

Mise à jour [2014/03/08]

Après de nouveaux tests et en répondant aux e-mails du support Tumblr, wgeta cessé de fonctionner (obtenir 403 erreurs sur les liens directs) à certaines occasions.

Mise à jour [2014/03/09]

La désactivation des règles Tumblr pour HTTPS-Everywhere semble parfois résoudre le problème.

_Remarque:

• _{Dans l'exemple pour # 6, les liens directs pointent tous deux vers la même image. Habituellement, cependant, celui utilisé dans la publication d'image (par rapport à la page d'image zoomable) utilise une version plus petite de l'image pour s'adapter au thème de la page. L'exemple utilise un thème conçu pour des écrans plus grands, il n'a donc pas besoin de la version plus petite.}

MISE À JOUR: Il semble que le problème principal avec les images ne se chargeant pas provienne de la façon dont le plugin / l'extension HTTPS Everywhere de l' EFF a géré certaines URL Tumblr. Le développeur a été informé et un correctif semble être en place . Cette réponse décompose essentiellement le travail de détective effectué pour découvrir le problème tel que décrit par la question initiale et pourrait s'avérer utile pour un débogage / diagnostic ultérieur si un problème similaire apparaît à l'avenir.

EDIT: Le plus grand contenu sur la sangsue d'image semble invalide. Donc, ajoutera une nouvelle idée en haut et laissera les informations de sangsue d'image en bas au cas où cela serait utile à quelqu'un.

Idées Amazon CloudFront CDN

D'accord, en utilisant les URL que vous avez fournies, ainsi que certaines de mes expériences réelles avec les configurations CDN d'Amazon CloudFront, je pense avoir découvert quelque chose. Il semble que la configuration Amazon CloudFront CDN de Tumblr s'étouffe pour une raison quelconque. Voici pourquoi je pense que c'est le cas.

Prenons cet exemple d'URL:

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

Maintenant, exécutons curl -Ipour obtenir les informations d'en-tête sur ce fichier:

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

La sortie pour cela serait quelque chose comme ceci:

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

Maintenant, les choses à faire attention ici sont les en- têtes Date(la date et l'heure du fichier sur le point de terminaison CloudFront) et X-Cache(l'état de livraison du contenu Amazon). Le comportement typique sur Amazon CloudFront est que le premier accès transmettra un «Miss de cloudfront» et puis si vous en faites un autre curl -Itout de suite après, il devrait y en avoir un Hit from cloudfront.

Mais ce n'est pas ce que j'ai vu tout à l'heure. Voici une ventilation de Dateet le X-Cachestatut d'un tas d'accès que j'ai fait:

• 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

La raison pour laquelle il existe plusieurs éléments avec les mêmes données exactes qui sont Hit from cloudfrontproches de la fin est parce que c'est ce qui se produit sur un CDN: si le point de terminaison du CDN a le fichier, puis Datecorrespond à la date de création / modification réelle du fichier qui point final a.

Vous remarquez que les quatre premiers accès sont distants de quelques secondes, avec des dates / heures différentes et tous le sont Miss from cloudfront, non? Cela signifie que le point de terminaison CDN rappelle simplement qu'il y a eu une tentative d'accès à ce fichier à ces moments et que toutes les tentatives ont échoué.

Donc, mon évaluation en fauteuil roulant de cela est que les systèmes de Tumblr ne suivent pas le CDN d'Amazon CloudFront ou que le CDN d'Amazon CloudFront ne suit pas avec Tumblr. Mais d'une certaine manière, les choses ne vont pas du côté serveur. Et comme il s'agit d'un CDN, une personne accédant aux fichiers à un emplacement peut ne pas remarquer de problème tandis qu'une autre personne à un autre emplacement aurait des problèmes pour visualiser l'image.

Tout cela pour dire que je ne pense pas que cela puisse être facilement réglé du côté client.

EDIT: Donc, l'affiche originale a ajouté de nouvelles URL, et cela pointe toujours vers un problème côté serveur, mais je voulais juste publier les détails pour l'enregistrement.

Idées CDN EdgeCast et Highwinds

Donc, l'affiche originale a ajouté plus de détails, alors voici plus de détails basés sur le blog qui est utilisé comme exemple:

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

Et ces URL d'image sont fournies à titre d'exemples d'URL dans cette publication:

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

Et ces deux URL d'images échouent en effet. Mais de mon côté - en regardant le code source d'origine du billet de blog de Brooklyn, New York, USA - je ne vois pas ces gs1.wac.edgecastcdn.netURL EdgeCast ( ). Ce sont plutôt les URL que je vois:

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

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

Donc, ma première pensée est pourquoi l'affiche originale voit-elle ces EdgeCast ( gs1.wac.edgecastcdn.net). Mais alors si je fais un traceroute vers le 41.media.tumblr.comje vois que c'est un serveur géré par Highwinds (!?!?). En revanche, les URL initiales transmises par l'utilisateur d'origine utilisent le 36.media.tumblr.comnom d'hôte et vous pouvez voir qu'elles sont gérées par les serveurs CDN Amazon CloudFront.

Tout cela pour dire - ce que j'ai dit auparavant - tout cela semble être un problème côté serveur avec Tumblr et leur gestion CDN. Mais de mon côté - à Brooklyn, New York, États-Unis - je vois clairement que le contenu est livré comme prévu à partir des serveurs CDN Highwinds ainsi que des serveurs CDN Amazon CloudFront. L'origine de ces URL EdgeCast ou comment / pourquoi elles échouent est hors du contrôle de quiconque du côté client. Ce serait certainement quelque chose pour contacter le personnel technique de Tumblr car il n'y a aucun moyen pour un utilisateur final de bureau de résoudre ce problème.

Idées de sangsue d'image

Peut-être plus pertinent, mais ici pour référence.

Vous déclarez cela me donne un indice:

L'utilisation wgetdes liens directs des images fonctionne.

De nombreux sites ont mis en place des règles, généralement définies via Apache, qui empêchent les sangsues d'images. Plus de détails sur le fonctionnement de ces règles sont fournis ici et sont résumés comme suit:

En utilisant .htaccess, vous pouvez interdire les liaisons à chaud sur votre serveur, de sorte que ceux qui tentent de créer un lien vers une image ou un fichier CSS sur votre site, par exemple, soit soit bloqués (demande échouée, telle qu'une image cassée), soit diffusés un contenu différent ( ex: une image d'un homme en colère).

D'après votre description - et le fait que vous puissiez accéder aux images via wget- me fait croire que les images avec lesquelles vous rencontrez des problèmes ne sont pas hébergées sur Tumblr par les utilisateurs, mais plutôt des images qui sont placées sur un blog Tumblr mais réellement hébergées sur un autre site.

Lorsque des procédures de sangsue d'image standard sont mises en place, l'affichage d'une image incorporée sur un site qui est hébergé sur un autre site - ce qui bloque la sangsue - entraînerait un lien d'image cassé ou peut-être un «Stop Leeching!» image retournée. Cela est dû au fait que les règles de base anti-sangsue, telles que celles de cette page d'exemple, vérifient les référents d'image pour s'assurer que la page demandant l'image correspond au domaine hébergeant l'image.

Ainsi, lorsque vous accédez à l'image via, wgetvous accédez directement à l'image. Ainsi, les règles de sangsue d'image ne se déclencheraient pas. Ainsi, vous pouvez obtenir l'image via wgetmais pas lorsqu'elle est intégrée dans une autre page.

J'ai actuellement ce même problème. Ceci est un coffre-fort pour le travail - eh bien c'est une bande dessinée idiote - exemple d'un blog affecté .

Si trouvé cependant que le problème ne s'est produit que dans Chrome pour moi. Après un certain temps, j'ai réalisé que la cause du problème était l'extension « HTTPS Everywhere ». Lorsque je l'ai installé dans Firefox, j'ai également eu le même problème. Et en fait, si je désactive la règle HTTPS «Tumblr (partiel)» (ce qui signifie *.tumblr.com, je suppose ), cela fonctionne à nouveau correctement.

Ainsi, le problème semble être que, au moins parfois , lorsque HTTPS est utilisé pour accéder à une image, vous êtes redirigé vers une URL EdgeCast non valide. Par exemple, cette URL d'image fonctionne correctement:

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

Mais si vous changez le protocole de httpen httpsvous êtes redirigé vers cette URL qui ne fonctionne pas:

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

Je ne sais pas si cela compte ou non comme une erreur du côté de Tumblr. Je suppose que si les clients ne sont pas censés accéder à leurs serveurs multimédias avec HTTPS, vous ne pouvez pas vraiment leur en vouloir.

EDIT: Et en fait, le problème semble avoir été traité comme indiqué dans ce fil GitHub .

J'ai remarqué ce comportement davantage sur mon opérateur de téléphonie mobile, T-Mobile. Je pense que c'est une sorte de mise en forme du trafic basée sur la taille de l'image ou une métrique de difficulté construite par le transporteur pour retrader ledit élément.

Lors de tests précédents - il y a plus d'un an -, j'ai ensuite partagé le message cassé avec un ami qui possède Verizon, et l'image se charge correctement.

Bien que je ne puisse pas tester cette image que je suis sur le point de fournir - car mon ami n'est pas disponible - cette image ne se charge pas pour moi. J'utilise Android (5.0.1) sur un Nexus 5 en utilisant Chrome comme navigateur.

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

Lorsque j'essaie de charger l'image directement, j'obtiens une erreur de temporisation de la passerelle 504.

EDIT: Ceci est @JakeGould affichant l'image réelle pour référence.

Autres tests et détails: je suis à Baltimore MD, à partir de données LTE et l'image suivante a fonctionné: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

Des tests supplémentaires montrent que PNG ne semble pas être le problème. La plupart des autres images que j'ai touchées qui fonctionnaient étaient un mélange de png et jpg, mais toutes étaient sur des serveurs non "41".

Note finale: je suis rentré chez moi, j'ai sauté sur mon wifi -Comcast- avec mon téléphone -l'appareil sur lequel j'ai testé- et toutes les photos que je n'ai pas pu voir en raison du 504 que je peux maintenant voir.

EDIT: Nouveau sur superutilisateur, article coupé et édité, donc c'était plus factuel et moins de discussion.

MISE À JOUR: Le problème semble être lié à LTE. Tumblr chargé, trouvé des images qui ne se chargeraient pas, a forcé mon téléphone à 3g, page rechargée, toutes les images montrent. Le téléphone est revenu au LTE, le cache vidé et les images qui ne se chargeaient pas auparavant sous LTE se chargent maintenant.
(Je teste à nouveau et maintenant je ne peux pas reproduire. Alors peut-être que le comportement ci-dessus était un coup de chance.)