UPDATE : Il semble que le problème de base avec les images qui ne se chargent pas provienne de la façon dont l'option Le plugin/extension HTTPS Everywhere de l'EFF a manipulé quelques URLs de Tumblr. Les développeurs ont été informés et une solution semble être en place . Cette réponse détaille le travail de détective effectué pour découvrir le problème tel qu'il est décrit dans la question initiale et peut s'avérer utile pour un débogage/diagnostic plus poussé si un problème similaire apparaît à l'avenir.
EDIT : Le contenu plus large sur le leeching d'image semble invalide. Je vais donc ajouter une nouvelle idée en haut de la page et laisser l'information sur le détournement d'image en bas de la page, au cas où elle serait utile à quelqu'un.
Idées de CDN Amazon CloudFront
D'accord, en utilisant les URL que vous avez fournies - ainsi qu'une partie de mon expérience réelle avec les configurations CDN d'Amazon CloudFront - je pense avoir découvert quelque chose. Il semble que la configuration CDN Amazon CloudFront de Tumblr s'étrangle 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 -I pour obtenir des informations sur l'en-tête de 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 auxquelles il faut faire attention ici sont les suivantes Date (la date et l'heure du fichier sur le point de terminaison CloudFront) et X-Cache (Amazon content delivery status). Le comportement typique d'Amazon CloudFront est que le premier accès transmettra un "Miss from cloudfront", puis si vous effectuez un autre accès de type curl -I tout de suite après, il devrait y avoir un Hit from cloudfront .
Mais ce n'est pas ce que je viens de voir. Voici une répartition de la Date y X-Cache l'état d'un groupe 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 y a plusieurs articles avec les mêmes données exactes qui sont Hit from cloudfront vers la fin est parce que c'est ce qui se passe sur un CDN : si le point d'arrivée du CDN a le fichier, alors Date correspond à la date réelle de création/modification du fichier dont dispose ce point d'extrémité.
Vous remarquez que les quatre premiers accès sont espacés de quelques secondes, avec des dates/heures différentes et tous sont Miss from cloudfront n'est-ce pas ? Cela signifie que le point de terminaison du CDN ne fait que répondre qu'il y a eu une tentative d'accès à ce fichier à ces moments-là et que toutes les tentatives ont échoué.
Je pense donc que les systèmes de Tumblr ne sont pas en phase avec le CDN d'Amazon CloudFront ou que le CDN d'Amazon CloudFront n'est pas en phase avec Tumblr. Mais d'une certaine manière, les choses ne vont pas bien du côté du serveur. Et puisqu'il s'agit d'un CDN, une personne accédant aux fichiers à un endroit peut ne pas remarquer de problème alors qu'une autre personne à un autre endroit aura des difficultés à visualiser l'image.
Tout cela pour dire que je ne pense pas que ce problème puisse être facilement résolu du côté du client.
EDIT : L'auteur de l'article original a ajouté de nouvelles URL, et il s'agit toujours d'un problème de serveur, mais je voulais simplement publier les détails pour mémoire.
Idées de CDN EdgeCast et Highwinds
L'auteur de l'affiche originale a donc ajouté des précisions. Voici donc des détails supplémentaires basés sur l'article de blog qui sert d'exemple :
http://claystorks.tumblr.com/post/112741831192/soulmister-claystorks-windspeare-explain
Et ces URLs d'images sont fournies comme exemples d'URLs dans ce post :
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 URLs d'images échouent en effet. Mais de mon côté, en regardant le code source original de l'article de blog de Brooklyn, New York, USA, je ne vois pas ces URL EdgeCast ( gs1.wac.edgecastcdn.net ) URLs. Ce sont plutôt les URLs que je vois :
http://41.media.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_500.png
http://41.media.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_1280.png
Ma première pensée est donc de savoir pourquoi l'affiche originale voit ces messages EdgeCast ( gs1.wac.edgecastcdn.net ). Mais si je fais un traceroute vers le site de 41.media.tumblr.com Je vois que c'est un serveur géré par Highwinds ( !?!?). En revanche, les URL initiales transmises par l'utilisateur d'origine utilisent l'attribut 36.media.tumblr.com et vous pouvez voir qu'ils sont gérés par les serveurs CDN Amazon CloudFront.
Tout cela pour dire - ce que j'ai déjà dit - que tout cela semble être un problème côté serveur avec Tumblr et leur gestion CDN. Mais de mon côté - à Brooklyn, New York, USA - je vois clairement que le contenu est livré comme prévu par les serveurs CDN de Highwinds ainsi que par les serveurs CDN d'Amazon CloudFront. L'origine de ces URL EdgeCast et la raison de leur échec échappent à tout contrôle du côté du client. Vous devez absolument contacter le personnel technique de Tumblr à ce sujet, car un utilisateur de bureau ne peut en aucun cas résoudre ce problème.
Idées d'accrochage d'images
Ce n'est peut-être plus d'actualité, mais c'est une référence.
Si tu dis ça, ça me donne un indice :
Utilisation de wget sur les 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 le piratage des images. Plus de détails sur le fonctionnement de ces règles sont fournis ici et se résume ainsi :
En utilisant le fichier .htaccess, vous pouvez interdire les liens dynamiques sur votre serveur. qui tentent de créer un lien vers une image ou un fichier CSS sur votre site, par exemple, est soit bloqué (échec de la demande, comme une image cassée) ou se voit servir un contenu différent (par exemple, l'image d'un homme en colère).
D'après votre description - et le fait que vous pouvez accéder aux images via wget -me porte à croire que les images qui vous posent problème ne sont pas hébergées sur Tumblr par les utilisateurs, mais plutôt des images placées sur un blog Tumblr mais hébergées en réalité sur un autre site.
Lorsque des procédures standard de leeching d'images sont mises en place, l'affichage d'une image intégrée sur un site qui est hébergé sur un autre site - qui bloque le leeching - se traduirait par un lien d'image cassé ou peut-être une image "Stop Leeching !". En effet, les règles de base contre le leeching, comme celles de la page d'exemple, vérifient les référents des images pour s'assurer que la page qui demande l'image correspond au domaine qui l'héberge.
Ainsi, lorsque vous accédez à l'image via wget vous accédez directement à l'image. Les règles de piratage de l'image ne s'appliquent donc pas. Ainsi, vous pouvez obtenir l'image via wget mais pas lorsqu'il est intégré dans une autre page.
