8 votos

¿Por qué las imágenes de algunas páginas de Tumblr no carga, pero el uso de wget en ellos obras?

Ayudando a un amigo con su conexión a Internet porque "algunas páginas no se carga", me di cuenta de que el problema era que las imágenes de algunos de los blogs de la imagen de los puestos no se carga en el navegador. Me pareció raro, porque de las siguientes razones:

  1. Sólo las imágenes que son parte del post no se carga. Usuario, avatares, banners, cabeceras, diversas tema y/o páginas relacionadas con imágenes siguen apareciendo.
  2. Sucede con cualquier navegador en el ordenador (Probado en Firefox y Chrome/ium con y sin ad/script bloqueadores).
  3. El uso de wget en las imágenes de' los enlaces directos de las obras.
  4. Esto no se aplica a todas las páginas de Tumblr. La mayoría de la carga correctamente, pero al hacer una lista de páginas con los posts que no carga las imágenes muestran que la mayoría son de la misma montón de usuarios.
  5. El problema parece ser del blog específico en el sentido de que si un determinado blog la imagen del post no se carga en el navegador, otros blogs (no afectado o no) que la publicación de reblogueada el mismo post que no se carga la imagen en el navegador, así. Por el contrario, si un blog es reblogs a partir de un afectado uno, la imagen se carga bien.
  6. Las imágenes son de los creados por el usuario de Tumblr a puestos en los que el usuario carga una imagen para publicar y están alojados en Tumblr. Por ejemplo (este ejemplo no es uno de los afectados blogs), en esta imagen de post (seleccionados al azar), este sería el enlace directo a la imagen en el post. Imagen de puestos de realizar automáticamente las imágenes de un enlace a otra página en Tumblr usando un (normalmente) una versión más grande de la imagen que se utiliza en el post que está más cerca del tamaño de lo que el usuario carga para el puesto.

Lo que posiblemente puede ser la razón para que esto ocurra? La parte que realmente me pone es el hecho de que wget obras, así que creo que puedo asumir que no es un problema con la conexión de red.

Actualización:

Aquí está un ejemplo de una publicación de reblogueada post que no se carga en el navegador. El blog principal tiene otra imagen de los puestos que se cargue correctamente. Este es el enlace directo a la imagen en el post y aquí está el uno para la versión más grande (tanto no se carga aquí). wget funciona para ambos, pero al ir a cualquier vínculo 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>

RequestID y HostId cambia cada vez. Mi amigo y yo estamos ubicados en Filipinas.

Actualización [2014/03/08]

Después de más pruebas y responder a los correos electrónicos de Tumblr apoyo, wget ha dejado de funcionar (llegar 403 errores en los enlaces directos) en algunas ocasiones.

Actualización [2014/03/09]

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


Nota:

  • En el ejemplo de la #6, enlaces directos ambos apuntan a la misma imagen. Generalmente, sin embargo, el que se utiliza en la imagen del post (en comparación con el zoom de la imagen de página) utiliza una versión más pequeña de la imagen para que se ajuste el 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.

10voto

JakeGould Puntos 17382

ACTUALIZACIÓN: parece Que el problema principal con imágenes que no se cargan deriva de la forma en que el FEP es HTTPS en todas partes plugin/extensión manejado algunas URLs de Tumblr. El desarrollador fueron notificados y una solución parece estar en su lugar. Esta respuesta, básicamente, se descompone el trabajo de investigación realizado para descubrir el problema, como señala la pregunta inicial y podría ser muy útil para la depuración más/diagnóstico si un problema similar en el futuro.


EDIT: La mayor cantidad de contenido sobre la imagen gorrones parece válido. Para añadir una nueva idea en la parte superior y dejar la imagen gorrones info en la parte inferior sólo en caso de que sea útil para alguien.

Amazon CloudFront CDN Ideas

Bueno, a través de las direcciones Url que usted ha proporcionado, así como algunos de mi experiencia en el mundo real con Amazon CloudFront CDN configuraciones-creo que he descubierto algo. Parece como Tumblr de Amazon CloudFront CDN config es la asfixia por alguna razón. He aquí por qué creo que es el caso.

Vamos a tomar esta dirección URL de ejemplo:

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

Ahora vamos a ejecutar curl -I para obtener información de encabezado en el archivo:

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

El resultado 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 las cosas para prestar atención al aquí están las Date (la fecha y hora de creación del archivo en el CloudFront extremo) y X-Cache (Amazon contenido de estado de entrega) de las cabeceras. La conducta típica en Amazon CloudFront es el primer acceso se transmiten de una "Señorita de cloudfront" y, a continuación, si usted no hace otra curl -I inmediatamente después debe haber un Hit from cloudfront.

Pero no es eso lo vi ahora. He aquí un desglose de la Date y X-Cache estado de un montón de accesos que yo 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 la misma exacta de los datos que son Hit from cloudfront cerca de la final es porque eso es lo que sucede en un CDN: Si el extremo de la CDN tiene el archivo, a continuación, Date corresponde a la creación real/fecha de modificación del archivo extremo que tiene.

Note los primeros cuatro de acceso son segundos de diferencia, con diferentes fechas/horas y todos ellos son Miss from cloudfront, ¿verdad? Eso significa que el extremo de CDN es sólo de repetir que hubo un intento de acceso que el archivo de los tiempos y de todos los intentos fueron echa de menos.

Así que mi sillón de evaluación de esto es que Tumblr es sistemas no están manteniendo con la de Amazon CloudFront CDN o la de Amazon CloudFront CDN no es mantenerse con Tumblr. Pero de alguna manera, las cosas están mal en su lado del servidor. Y ya que este es un CDN, alguien acceder a los archivos en una ubicación puede no darse cuenta de un problema, mientras que otra persona en otro lugar habría problemas de visualización de la imagen.

Que es todo lo que decir, no creo que esto puede ser aclarado en el lado del cliente.


EDIT: por Lo que el cartel original añadido algunas nuevas direcciones Url, y esto todavía apunta a un problema de servidor, pero yo sólo quería publicar los detalles para el registro.

EdgeCast & Highwinds CDN Ideas

Así que el cartel original añadido más detalles, así que aquí están más detalles basándose en la entrada de blog que está siendo utilizado como un ejemplo:

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

Y estas Url de imagen se proporcionan como ejemplos de direcciones Url en la que el 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

Y esas dos Url de imagen, de hecho fracasar. Pero a partir de mi lado-mirando el original de soure código de la entrada de blog de Brooklyn, Nueva York, estados UNIDOS-no estoy viendo los EdgeCast (gs1.wac.edgecastcdn.net) direcciones Url. Más bien, estas son las direcciones Url estoy viendo:

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

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

Así que mi primer pensamiento es ¿por qué es el cartel original de ver los EdgeCast (gs1.wac.edgecastcdn.net). Pero entonces, si yo hago un traceroute a la 41.media.tumblr.com veo que es un servidor administrado por Highwinds (!?!?). En contraste, la inicial Url pasan por el usuario original está utilizando el 36.media.tumblr.com nombre de host y se puede ver que son gestionados por Amazon CloudFront CDN servidores.

Que es todo lo que decir-lo que me dijo antes de todo esto parece ser un servidor de lado el problema con Tumblr y sus CDN de gestión. Pero a partir de mi lado-en Brooklyn, Nueva York, estados UNIDOS-estoy viendo claramente contenido que se entregan como se esperaba desde el CDN de Highwinds servidores, así como Amazon CloudFront CDN servidores. Donde estas EdgeCast URL vienen o cómo/por qué están a continuación, no está fuera de control en el lado del cliente. Este sería, sin duda algo para contactar Tumblr personal técnico acerca de porque no hay forma de que un escritorio para el usuario final podría resolver esto.


Imagen Gorrones Ideas

Podría no ser relevante, pero aquí por referencia.

Usted afirmar esto me da una idea:

El uso de wget en las imágenes de' los enlaces directos de las obras.

Muchos sitios tienen reglas en el lugar-generalmente se establecen a través de Apache-que impiden la imagen de gorrones. Más detalles acerca de cómo esas reglas de trabajo se dan a continuación y se resumen como este:

El uso de .htaccess, usted puede desactivar hot-linking en su servidor, por lo que aquellos intentar vincular a una imagen o archivo CSS en el sitio, por ejemplo, está bloqueada (error de solicitud, tales como una imagen rota) o se sirve un contenido diferente (es decir: una imagen de un hombre enojado).

Con base en la descripción-y el hecho de que usted puede acceder a las imágenes a través de wget-me lleva a creer que las imágenes que usted está teniendo problemas con no se hospedan en Tumblr por parte de los usuarios, sino de las imágenes que se colocan en un blog de Tumblr, pero en realidad alojado en otro sitio.

Cuando la imagen estándar de gorrones de procedimientos, la visualización de una imagen incrustada en una web que está alojado en otro sitio-que bloquea los gorrones-daría lugar a una fractura en el vínculo de la imagen o tal vez un "Stop Gorrones!" de la imagen que se devuelve. Esto es porque básicos anti-gorrones reglas, como aquellos en que el ejemplo de la página-crosscheck imagen de referentes para asegurarse de que la página que solicita la imagen coincide con el dominio que aloja la imagen.

Así que cuando se accede a la imagen a través de wget está accediendo directamente la imagen. Así que la imagen gorrones normas no entran en juego. Por lo tanto usted puede conseguir la imagen a través de wget , pero no cuando se está incrustado en otra página.

5voto

jdehesa Puntos 141

Actualmente estoy teniendo este problema. Este es un seguro para el trabajo-bueno, es una tontería en la comic- ejemplo de un blog.

Si se encuentra, sin embargo, que el problema ocurrió sólo en Chrome para mí. Después de un tiempo, me di cuenta de que la causa del problema fue la extensión "HTTPS en todas partes." Cuando he instalado en Firefox, yo tenía el mismo problema. Y en realidad, si puedo desactivar el HTTPS regla de "Tumblr (parcial)" (que supongo que significa *.tumblr.com), funciona bien de nuevo.

Así, el problema parece ser que, al menos a veces, cuando HTTPS es utilizado para acceder a una imagen, se le redirige a un inválido EdgeCast URL. Por ejemplo, esta URL de la imagen funciona bien:

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

Pero si cambia el protocolo de http a https usted conseguir redirigido a esta dirección 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 de Tumblr lado o no. Supongo que si los clientes no deben tener acceso a sus servidores de medios con HTTPS realmente no se puede culpar a ellos.

EDIT: Y en realidad el problema parece haber sido tratada como se informó en este GitHub hilo.

1voto

userWCB Puntos 11

Me he dado cuenta de este comportamiento más, mientras que en el operador de telefonía móvil T-Mobile. Estoy pensando que esto es algún tipo de traffic shaping basa en el tamaño de la imagen o algún transportista construido "dificultad métrica" en retreaving dicho elemento.

En pruebas anteriores-hace más de un año-he compartido, a continuación, el roto post a un amigo que ha Verizon, y la imagen se carga bien.

Mientras que no se puede probar esta imagen que les voy a ofrecer-como mi amigo no está disponible-esta imagen no se carga para mí. Estoy corriendo stock de Android (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 tengo un 504 gateway timeout error.

EDIT: Este es @JakeGould la publicación de la real de la imagen de referencia.

enter image description here

Más pruebas y detalles: estoy en Baltimore MD, corriendo de datos LTE y en la imagen siguiente se hizo el trabajo: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

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

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

EDIT: Nuevo superusuario, cortado y editado el post por lo que es más objetiva y menos discusión.

ACTUALIZACIÓN:el Problema parece estar ligada a LTE. Cargado de tumblr, encontrado algunas imágenes que no carga, obligó a mi teléfono 3g, vuelve a cargar la página, todas las imágenes que se muestran. Revertir teléfono LTE, se borra la memoria caché y las imágenes que antes no se carga en LTE ahora de carga.
(Estoy probando de nuevo y ahora no puedo reproducir. Así que tal vez el comportamiento anterior fue un golpe de suerte.)

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: