¿Por qué las imágenes de algunas páginas de Tumblr no se cargan, pero usar wget en ellas funciona?

Al ayudar a un amigo con su conexión a Internet porque "algunas páginas no se cargan", noté que el problema era que las imágenes de las publicaciones de imágenes de ciertos blogs no se cargaban en el navegador. Me pareció extraño por las siguientes razones:

1. Solo las imágenes que forman parte de la publicación no se cargarán. Todavía aparecen avatares de usuario, pancartas, encabezados, varios temas y / o imágenes relacionadas con la página.
2. Ocurre con cualquier navegador en la computadora (Probado en Firefox y Chrome / ium con y sin bloqueadores de anuncios / guiones).
3. El uso wgetde los enlaces directos de las imágenes funciona.
4. Esto no se aplica a todas las páginas de Tumblr. La mayoría se carga correctamente, pero cuando se hace una lista de páginas con publicaciones que no cargan imágenes, se muestra que provienen principalmente del mismo grupo de usuarios.
5. El problema parece ser específico de un blog en el sentido de que si la publicación de una imagen de blog no se carga en el navegador, otros blogs (no afectados o no) que hayan publicado la misma publicación tampoco cargarán la imagen en el navegador. Por el contrario, si un blog afectado no se ve afectado, la imagen se carga bien.
6. Las imágenes son de publicaciones de Tumblr creadas por el usuario donde el usuario carga una imagen para publicar y están alojadas por Tumblr. Por ejemplo (este ejemplo no es uno de los blogs afectados), en esta publicación de imagen (seleccionada al azar), este sería el enlace directo a la imagen en la publicación. Las publicaciones de imágenes hacen que las imágenes sean un enlace a otra página en Tumblr utilizando una versión (generalmente) más grande de la imagen utilizada en la publicación que se acerca más al tamaño de lo que el usuario cargó para la publicación.

¿Cuál puede ser la razón de que esto suceda? La parte que realmente me atrapa es el hecho de que wgetfunciona, así que creo que puedo asumir que no es un problema con la conexión de red.

Actualizar:

Aquí hay un ejemplo de una publicación publicada que no se carga en los navegadores. El blog principal tiene otras publicaciones de imágenes que se cargan correctamente. Este es el enlace directo a la imagen en la publicación y aquí está el de la versión más grande (ambos no se cargan aquí). wgetfunciona para ambos, pero al ir a cualquier enlace directo con Firefox, aparece este error:

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>

RequestIDy HostIdcambia cada vez. Mi amigo y yo estamos ubicados en Filipinas.

Actualización [2014/03/08]

Tras más pruebas y respondiendo a los correos electrónicos de soporte de Tumblr, wgetha dejado de funcionar (obteniendo 403 errores en enlaces directos) en algunas ocasiones.

Actualización [2014/03/09]

Apagar las reglas de Tumblr para HTTPS-Everywhere parece solucionar el problema a veces .

_Nota:

• _{En el ejemplo para el n. ° 6, los enlaces directos apuntan a la misma imagen. Por lo general, sin embargo, el que se usa en la publicación de la imagen (en comparación con la página de imagen con zoom) usa una versión más pequeña de la imagen para adaptarse al tema de la página. El ejemplo utiliza un tema hecho para pantallas más grandes, por lo que no necesita la versión más pequeña.}

ACTUALIZACIÓN: Parece que el problema principal con las imágenes que no se cargan proviene de la forma en que el complemento / extensión HTTPS Everywhere del EFF manejó algunas URL de Tumblr. Se notificó a los desarrolladores y parece haber una solución . Esta respuesta básicamente desglosa el trabajo de detective realizado para descubrir el problema como se describe en la pregunta inicial y podría resultar útil para una mayor depuración / diagnóstico si aparece un problema similar en el futuro.

EDITAR: El contenido más grande sobre la sangría de imágenes parece no válido. Por lo tanto, agregará una nueva idea en la parte superior y dejará la información de la imagen en la parte inferior en caso de que sea útil para alguien.

Ideas de Amazon CloudFront CDN

De acuerdo, usando las URL que ha proporcionado, así como parte de mi experiencia en el mundo real con las configuraciones de CDN de Amazon CloudFront, creo que descubrí algo. Parece que la configuración CDN de Amazon CloudFront de Tumblr se está ahogando por alguna razón. Aquí es por qué creo que ese es el caso.

Tomemos este ejemplo de URL:

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

Ahora corramos curl -Ipara obtener información de encabezado en ese archivo:

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

La salida para eso sería algo como esto:

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

Ahora, lo que hay que prestar atención aquí son los encabezados Date(la fecha y hora del archivo en el punto final de CloudFront) y X-Cache(estado de entrega de contenido de Amazon). El comportamiento típico en Amazon CloudFront es que el primer acceso transmitirá un "Miss desde el frente de la nube" y luego, si hace otro de curl -Iinmediato, debería haber un Hit from cloudfront.

Pero eso no es lo que vi hace un momento. Aquí hay un desglose del estado Datey X-Cachede un montón de accesos que hice:

• 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 razón por la que hay varios elementos con los mismos datos exactos que están Hit from cloudfrontcerca del final es porque eso es lo que sucede en una CDN: si el punto final de la CDN tiene el archivo, entonces se Datecorrelaciona con la fecha real de creación / modificación del archivo que punto final tiene.

Te das cuenta de que los primeros cuatro accesos están separados por segundos, con diferentes fechas / horas y todos ellos Miss from cloudfront, ¿verdad? Eso significa que el punto final de CDN solo está repitiendo que hubo un intento de acceder a ese archivo en esos momentos y que todos los intentos fueron fallidos.

Entonces, mi evaluación de esto es que los sistemas de Tumblr no están al día con Amazon CloudFront CDN o que Amazon CloudFront CDN no está al día con Tumblr. Pero de alguna manera, las cosas están mal en su lado del servidor. Y dado que se trata de un CDN, alguien que acceda a los archivos en una ubicación podría no notar un problema, mientras que otra persona en otra ubicación tendría problemas para ver la imagen.

Lo cual es todo para decir, no creo que esto pueda aclararse fácilmente en el lado del cliente.

EDITAR: Entonces, el póster original agregó algunas URL nuevas, y esto todavía apunta a un problema del lado del servidor, pero solo quería publicar los detalles para el registro.

Ideas de CDN de EdgeCast & Highwinds

Entonces, el póster original agregó más detalles, así que aquí hay más detalles basados ​​en la publicación del blog que se está utilizando como ejemplo:

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

Y estas URL de imágenes se proporcionan como ejemplos de URL en esa publicación:

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

Y esas dos URL de imágenes realmente fallan. Pero desde mi lado, mirando el código original de la publicación del blog de Brooklyn, Nueva York, EE. UU., No veo esas gs1.wac.edgecastcdn.netURL de EdgeCast ( ). Más bien, estas son las URL que estoy viendo:

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

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

Entonces, mi primer pensamiento es por qué el póster original está viendo esos EdgeCast ( gs1.wac.edgecastcdn.net). Pero luego, si hago un traceroute al 41.media.tumblr.com, veo que es un servidor administrado por Highwinds (!?!?). Por el contrario, las URL iniciales transmitidas por el usuario original utilizan el 36.media.tumblr.comnombre de host y puede ver que son administradas por servidores CDN de Amazon CloudFront.

Lo cual es todo para decir, lo que dije antes, todo esto parece ser un problema del lado del servidor con Tumblr y su gestión de CDN. Pero desde mi lado, en Brooklyn, Nueva York, EE. UU., Veo claramente que el contenido se entrega como se espera de los servidores CDN de Highwinds, así como de los servidores CDN de Amazon CloudFront. De dónde provienen estas URL de EdgeCast o cómo / por qué están fallando está fuera del control de nadie en el lado del cliente. Esto definitivamente sería algo para contactar al personal técnico de Tumblr porque no hay forma de que un usuario final de escritorio pueda resolver esto.

Image Leeching Ideas

Puede que ya no sea relevante, pero aquí para referencia.

Afirmas esto, dame una pista:

El uso wgetde los enlaces directos de las imágenes funciona.

Muchos sitios tienen reglas establecidas, generalmente establecidas a través de Apache, que evitan la pérdida de imágenes. Aquí se proporcionan más detalles sobre cómo funcionan esas reglas y se resume así:

Con el uso de .htaccess, puede deshabilitar los enlaces activos en su servidor, por lo que aquellos que intentan enlazar a una imagen o archivo CSS en su sitio, por ejemplo, se bloquean (solicitud fallida, como una imagen rota) o se sirve un contenido diferente ( es decir: una imagen de un hombre enojado).

Según su descripción, y el hecho de que puede acceder a las imágenes a través de, wgetme lleva a creer que las imágenes con las que tiene problemas no están alojadas en Tumblr por los usuarios, sino más bien imágenes que se colocan en un blog de Tumblr pero en realidad se alojan en otro sitio.

Cuando se implementan los procedimientos estándar de imágenes sanguijuelas, ver una imagen incrustada en un sitio alojado en otro sitio, que bloquea las sanguijuelas, daría como resultado un enlace de imagen roto o tal vez un "¡Detener la sanguijuela!" imagen devuelta Esto se debe a que las reglas básicas anti-sanguijuelas, como las de esa página de ejemplo, verifican las referencias de imágenes para asegurarse de que la página que solicita la imagen coincida con el dominio que aloja la imagen.

Entonces, cuando está accediendo a la imagen a través de wget, está accediendo a la imagen directamente. Por lo tanto, las reglas de sanguijuela de la imagen no entrarían en vigencia. Por lo tanto, puede obtener la imagen a través de, wgetpero no cuando está incrustada en otra página.

Actualmente estoy teniendo este mismo problema. Este es un ejemplo seguro para el trabajo, bueno, es un cómic tonto, de un blog afectado .

Sin embargo, si descubrí que el problema solo ocurrió en Chrome para mí. Después de un tiempo, me di cuenta de que la causa del problema era la extensión " HTTPS Everywhere ". Cuando lo instalé en Firefox, tuve el mismo problema allí también. Y, de hecho, si desactivo la regla HTTPS "Tumblr (parcial)" (lo que supongo que significa *.tumblr.com), vuelve a funcionar bien.

Entonces, el problema parece ser que, al menos a veces , cuando se utiliza HTTPS para acceder a una imagen, se lo redirige a una URL de EdgeCast no válida. Por ejemplo, esta URL de imagen funciona bien:

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

Pero si cambia el protocolo de httpa https, será redirigido a esta URL que no funciona:

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

No estoy seguro de si esto cuenta como un error del lado de Tumblr o no. Supongo que si no se supone que los clientes accedan a sus servidores de medios con HTTPS, realmente no se les puede culpar por ello.

EDITAR: Y en realidad el problema parece haber sido resuelto como se informa en este hilo de GitHub .

He notado este comportamiento más en mi operador de telefonía móvil, T-Mobile. Estoy pensando que esta es una especie de conformación del tráfico basada en el tamaño de la imagen o alguna "métrica de dificultad" construida por el transportista para recuperar dicho artículo.

En pruebas anteriores, hace más de un año, compartí la publicación rota con un amigo que tiene Verizon, y la imagen se carga bien.

Si bien no puedo probar esta imagen, estoy a punto de proporcionarla, ya que mi amigo no está disponible, esta imagen no se carga para mí. Estoy ejecutando Android Stock (5.0.1) en un Nexus 5 usando Chrome como navegador.

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

Cuando intento cargar la imagen directamente, aparece un error de tiempo de espera de la puerta de enlace 504.

EDITAR: Esta es @JakeGould publicando la imagen real como referencia.

Pruebas y detalles adicionales: estoy en Baltimore MD, me estoy quedando sin datos LTE y la siguiente imagen funcionó: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

Más pruebas muestran que PNG no parece ser el problema. La mayoría de las otras imágenes que golpeé que funcionaron eran una mezcla de png y jpg, pero todas estaban en servidores que no eran "41".

Nota final: llegué a casa, encendí mi wifi -Comcast- con mi teléfono -el dispositivo en el que he estado probando- y todas las fotos que no pude ver debido al 504 que ahora puedo ver.

EDITAR: Nueva publicación para superusuario, recortada y editada, por lo que fue más objetiva y menos discutida.

ACTUALIZACIÓN: El problema parece estar relacionado con LTE. Cargué tumblr, encontré algunas imágenes que no se cargaban, forcé mi teléfono a 3g, volví a cargar la página, se muestran todas las imágenes. Volvió el teléfono a LTE, borró la memoria caché y ahora se cargan las imágenes que anteriormente no se cargaban con LTE.
(Estoy probando nuevamente y ahora no puedo reproducirme. Entonces, tal vez el comportamiento anterior fue una casualidad).