web-dev-qa-db-fra.com

Pourquoi les images de certaines pages Tumblr ne se chargent-elles pas mais utilisent-elles wget?

Aider un ami avec sa connexion Internet parce que "certaines pages ne se chargent pas", j’ai remarqué que le problème était que les images des messages d’image de certains blogs ne se téléchargeaient pas dans le navigateur. J'ai trouvé ça bizarre pour les raisons suivantes:

  1. Seules les images faisant partie de la publication ne seront pas chargées. Des avatars, des bannières, des en-têtes, divers thèmes et/ou images associées à des pages apparaissent toujours.
  2. Cela se produit avec n’importe quel navigateur de l’ordinateur (testé sur Firefox et Chrome/ium, avec et sans bloqueurs d’annonce/script).
  3. Utiliser wget sur les liens directs des images fonctionne.
  4. Cela ne s'applique pas à toutes les pages Tumblr. La plupart se chargent correctement, mais lorsqu’une liste de pages contenant des publications qui ne chargent pas d’images montre qu’elles proviennent principalement du même groupe d’utilisateurs.
  5. Le problème semble être spécifique à un blog en ce sens que si un article de blog ne se charge pas dans le navigateur, les autres blogs (non affectés ou non) qui ont eu le même message ne chargeront pas l'image dans le navigateur. Inversement, si un blog affecté est une publication de journal non affecté, l'image se charge correctement.
  6. Les images proviennent de publications Tumblr créées par l'utilisateur, dans lesquelles l'utilisateur télécharge une image à publier. Elles sont hébergées par Tumblr. Par exemple (cet exemple n’est pas l’un des blogs affectés), dans cette image post (sélectionnée au hasard), ceci serait le lien direct lien vers l'image dans le post. Les publications d'images 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 le message.

Quelle peut être la raison de cela? Ce qui me tient vraiment à cœur est le fait que wget fonctionne, alors je pense pouvoir supposer que ce n’est pas un problème de connexion réseau.

Mise à jour:

Here est un exemple de publication a échoué 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 l'article et ici est celui de la version plus grande (les deux ne se chargent pas ici) . wget fonctionne pour les deux, mais en allant sur un 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>

RequestID et HostId changent à chaque fois. Mon ami et moi sommes situés aux Philippines.

Mise à jour [2014/03/08]

Lors de tests supplémentaires et après avoir répondu aux e-mails du support Tumblr, wget a cessé de fonctionner (en obtenant 403 erreurs sur des liens directs) à certaines occasions.

Mise à jour [2014/03/09]

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

Remarque:

  • Dans l'exemple de # 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 pouvant être agrandie) 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 les écrans plus grands, il n'a donc pas besoin de la version plus petite.
google-chromefirefoxwgetchromium
8
maki57

UPDATE: Il semble que le problème principal concernant les images qui ne se chargent pas de charger provient de la façon dont le Le plugin/extension HTTPS Everywhere de EFF gérait certaines URL Tumblr. Les développeurs ont été notifiés et un correctif semble être en place . Cette réponse décompose en gros le travail de détective effectué pour découvrir le problème décrit dans la question initiale et pourrait s'avérer utile pour un débogage/diagnostic plus approfondi si un problème similaire se présentait à l'avenir.

EDIT: Le contenu plus volumineux relatif à la perte d'image semble invalide. Ainsi, nous ajouterons une nouvelle idée en haut et laisserons les informations de perte d’image en bas au cas où cela serait utile à quelqu'un.

Idées CDN Amazon CloudFront

OK, 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 CDN d’Amazon CloudFront é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

Lançons maintenant curl -I pour 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 ressemblerait à 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==

À présent, les éléments à surveiller sont les en-têtes Date (la date et l'heure du fichier sur le point de terminaison CloudFront) et X-Cache (état de livraison du contenu Amazon). Le comportement typique sur Amazon CloudFront est le premier accès qui transmettra un "Miss de cloudfront", puis si vous faites un autre curl -I immédiatement après, il devrait y avoir un Hit from cloudfront.

Mais ce n’est pas ce que j’ai vu tout à l’heure. Voici une ventilation de l'état Date et X-Cache d'un groupe d'accès que j'ai obtenus:

  • 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 éléments avec les mêmes données exactes qui sont Hit from cloudfront près de la fin est parce que c'est ce qui se produit sur un CDN: Si le noeud final du CDN contient le fichier, alors Date correspond à la date de création/modification du fichier. fichier que le point final a.

Vous remarquez que les quatre premiers accès sont séparés par des secondes, avec des dates/heures différentes et qu'ils sont tous au format Miss from cloudfront, n'est-ce pas? Cela signifie que le point de terminaison CDN ne fait que répéter que nous avons tenté d'accéder à ce fichier à ce moment-là et que toutes les tentatives ont été infructueuses.

Donc, d'après mon évaluation, les systèmes de Tumblr ne suivent pas le CDN Amazon CloudFront ou le CDN Amazon CloudFront ne suit pas le rythme de Tumblr. Mais d'une certaine manière, les choses vont mal du côté serveur. Et puisqu'il s'agit d'un CDN, il est possible qu'une personne accédant aux fichiers à un emplacement donné ne remarque pas un problème, tandis qu'une autre personne située à un autre emplacement aurait des problèmes d'affichage de l'image.

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

EDIT: Ainsi, l'affiche d'origine a ajouté de nouvelles URL, ce qui pointe toujours vers un problème côté serveur, mais Je voulais juste poster les détails pour l'enregistrement.

Idées CDN EdgeCast et Highwinds

Ainsi, l'affiche originale a ajouté plus de détails, voici donc plus de détails basés sur l'article de blog utilisé à titre d'exemple:

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

Et ces URL d'image sont fournies à titre d'exemple d'URL dans cet article:

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'image échouent effectivement. Mais de mon côté - en regardant le code source original de l'article de blog de Brooklyn, New York, États-Unis -, je ne vois pas ces URL EdgeCast (gs1.wac.edgecastcdn.net). 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 de savoir pourquoi l’affiche originale voit ces EdgeCast (gs1.wac.edgecastcdn.net). Mais alors si je fais un traceroute au 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 le nom d'hôte 36.media.tumblr.com et vous pouvez voir qu'elles sont gérées par les serveurs CDN d'Amazon CloudFront.

Ce qui revient à dire - ce que j'ai déjà dit auparavant - tout cela semble être un problème côté serveur avec Tumblr et leur gestion de CDN. Mais de mon côté, à Brooklyn, à New York, aux États-Unis, je vois clairement que le contenu est livré comme prévu par les serveurs Highwinds CDN ainsi que par les serveurs Amazon CloudFront CDN. L’origine de ces URL EdgeCast, ou pourquoi/pourquoi elles échouent, échappe au contrôle de quiconque du côté client. Contacter le personnel technique de Tumblr serait certainement un sujet intéressant, car aucun utilisateur final de bureau ne pourrait résoudre ce problème.

Image Idées Leeching

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

Vous dites cela, donnez-moi un indice:

Utiliser wget sur les liens directs des images fonctionne.

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

À l'aide de .htaccess, vous pouvez interdire les liens dynamiques sur votre serveur. Ainsi, ceux qui tentent de créer un lien vers une image ou un fichier CSS de votre site sont soit bloqués (demande échouée, telle qu'une image endommagée), soit diffusés avec un contenu différent ( c'est à dire: une image d'un homme en colère).

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

Lorsque des procédures standard de récupération d’image sont mises en place, la visualisation d’une image intégrée sur un site hébergé sur un autre site (ce qui bloque la suppression) produirait un lien d’image brisé ou peut-être une image "Arrêter la récupération!". Cela est dû au fait que les règles anti-abaissement de base, telles que celles de cet exemple de page, vérifient la correspondance des référents d’image pour s’assurer que la page demandant l’image correspond au domaine qui l’héberge.

Ainsi, lorsque vous accédez à l'image via wget, vous accédez directement à l'image. Ainsi, les règles d’extraction de l’image ne s’appliqueraient pas. Ainsi, vous pouvez obtenir l’image via wget, mais pas si elle est incorporée dans une autre page.

10
JakeGould

J'ai actuellement ce même problème. C’est un coffre-fort pour le travail - bon, c’est une bande dessinée stupide - , exemple d’un blog touché .

Si trouvé cependant que le problème ne s'est produit que dans Chrome pour moi. Après un moment, je me suis rendu compte que le problème était lié à l'extension “ HTTPS Everywhere .” Lorsque je l'ai installé dans Firefox, j'ai eu le même problème. ici aussi. Et en fait, si je désactive la règle HTTPS "Tumblr (partielle)" (ce qui signifie, je suppose, *.tumblr.com), cela fonctionnera à nouveau.

Le problème semble donc ê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 http à https, vous serez 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 de médias avec HTTPS, vous ne pouvez pas vraiment leur en vouloir.

EDIT: Et effectivement, le problème semble avoir été résolu , comme indiqué dans ce fil GitHub .

5
jdehesa

J'ai constaté ce comportement plus souvent chez mon opérateur de téléphonie mobile, T-Mobile. Je pense qu’il s’agit d’une forme de lissage du trafic basée sur la taille de l’image ou d’un "indicateur de difficulté" construit par le transporteur lors de la reprise en arrière dudit élément.

Lors de tests précédents, il y a plus d'un an, j'avais ensuite partagé le message cassé avec un ami de Verizon, et l'image se chargeait bien.

Bien que je ne puisse pas tester cette image que je m'apprête à fournir - mon ami n'étant pas disponible - cette image ne se charge pas. J'utilise Android (5.0.1) avec un Nexus 5 sous Chrome en tant que navigateur.

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

Lorsque j'essaie de charger directement l'image, une erreur de délai d'attente de la passerelle 504 s'affiche.

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

enter image description here

Autres tests et précisions: je suis à Baltimore MD, avec LTE données et l’image suivante ont fonctionné: http://40.media.tumblr.com /a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

Des tests supplémentaires montrent que la PNG ne semble pas être le problème. La plupart des autres images qui ont fonctionné étaient un mélange de png et de jpg, mais toutes portaient sur des serveurs autres que "41".

Note finale: Je suis rentré chez moi, sauté sur mon wifi -Comcast- avec mon téléphone -le dispositif sur lequel je testais- et toutes les photos que je ne pouvais pas voir à cause de la 504 que je peux maintenant voir.

EDIT: Nouveau sur superutilisateur, ajusté et édité après afin que ce soit plus factuel et moins de discussion.

UPDATE: Le problème semble lié à LTE. Tumblr chargé, trouvé des images qui ne se chargeaient pas, forcé mon téléphone à passer à 3g, page rechargée, toutes les images sont affichées. Le téléphone est retourné en mode LTE, le cache est effacé et les images qui ne se chargeaient pas auparavant sous LTE sont maintenant chargées.
(Je teste à nouveau et maintenant je ne peux plus me reproduire. Alors peut-être que le comportement ci-dessus était un coup de chance.)

1
userWCB