Por que as imagens de algumas páginas do Tumblr não são carregadas, mas o uso do wget nelas funciona?

Ajudando um amigo com a conexão à Internet porque "algumas páginas não carregam", notei que o problema era que as imagens das postagens de determinadas imagens de blogs não estavam sendo carregadas no navegador. Achei estranho por causa dos seguintes motivos:

1. Somente as imagens que fazem parte da postagem não serão carregadas. Avatares de usuários, banners, cabeçalhos, vários temas e / ou imagens relacionadas à página ainda aparecem.
2. Acontece com qualquer navegador do computador (testado no Firefox e Chrome / ium, com e sem bloqueadores de anúncios / scripts).
3. O uso wgetdos links diretos das imagens funciona.
4. Isso não se aplica a todas as páginas do Tumblr. A maioria é carregada corretamente, mas ao fazer uma lista de páginas com postagens que não carregam imagens, mostra que elas são principalmente do mesmo grupo de usuários.
5. O problema parece ser específico do blog, no sentido de que, se uma determinada postagem de imagem de um blog não carregar no navegador, outros blogs (afetados ou não) que fizeram o mesmo post não carregarão a imagem no navegador também. Por outro lado, se um blog afetado é reblogado de um não afetado, a imagem carrega bem.
6. As imagens são de postagens do Tumblr criadas pelo usuário, nas quais o usuário carrega uma imagem para postar e são hospedadas no Tumblr. Por exemplo (este exemplo não é um dos blogs afetados), nesta postagem de imagem (selecionada aleatoriamente), esse seria o link direto para a imagem na postagem. As postagens de imagem transformam automaticamente as imagens em um link para outra página no Tumblr usando uma versão (geralmente) maior da imagem usada na postagem, mais próxima do tamanho do que o usuário enviou para a postagem.

Qual pode ser a razão para isso acontecer? A parte que realmente me emociona é o fato de wgetfuncionar, então acho que posso assumir que não há problema com a conexão de rede.

Atualizar:

Aqui está um exemplo de uma postagem de download que falha ao carregar nos navegadores. O blog principal possui outras postagens de imagem que são carregadas corretamente. Este é o link direto para a imagem no post e aqui está o da versão maior (ambos não carregam aqui). wgetfunciona para ambos, mas ao acessar qualquer link direto com o Firefox, este erro aparece:

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>

RequestIDe HostIdmuda sempre. Meu amigo e eu estamos localizados nas Filipinas.

Atualização [08/03/2014]

Após testes adicionais e resposta aos e-mails do suporte do Tumblr, wgetparou de funcionar (recebendo 403 erros em links diretos) em algumas ocasiões.

Atualização [09/09/2014]

Desligar as regras Tumblr para HTTPS Everywhere-parece , por vezes, resolver o problema.

_Nota:

• _{No exemplo do item 6, os links diretos apontam para a mesma imagem. Geralmente, porém, o usado na postagem da imagem (em comparação com a página de imagem com zoom) usa uma versão menor da imagem para se ajustar ao tema da página. O exemplo usa um tema criado para telas maiores, para que não precise da versão menor.}

ATUALIZAÇÃO: Parece que o principal problema com as imagens não carregadas decorreu da maneira como o plug-in / extensão HTTPS Everywhere da EFF lidou com alguns URLs do Tumblr. O desenvolvedor foi notificado e uma correção parece estar em vigor . Essa resposta basicamente divide o trabalho de detetive feito para descobrir o problema, conforme descrito na pergunta inicial, e pode ser útil para depuração / diagnóstico adicional, se um problema semelhante aparecer no futuro.

EDIT: O conteúdo maior sobre leeching de imagem parece inválido. Então, adicione uma nova idéia na parte superior e deixe as informações sobre a imagem na parte inferior, caso seja útil para alguém.

Ideias do CDN do Amazon CloudFront

Tudo bem, usando os URLs que você forneceu - assim como parte da minha experiência no mundo real com as configurações do Amazon CloudFront CDN - acho que descobri algo. Parece que a configuração da Amazon CloudFront CDN do Tumblr está sufocando por algum motivo. Eis por que acho que é esse o caso.

Vamos pegar este URL de exemplo:

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

Agora vamos correr curl -Ipara obter informações de cabeçalho nesse arquivo:

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

A saída para isso seria algo como isto:

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

Agora, o que deve ser observado aqui são os cabeçalhos Date(a data e a hora do arquivo no terminal do CloudFront) e X-Cache(status de entrega de conteúdo da Amazon). O comportamento típico no Amazon CloudFront é o primeiro acesso que transmite uma "falha do cloudfront" e, se você fizer outro curl -Iimediatamente depois, deve haver um Hit from cloudfront.

Mas não foi o que vi agora. Aqui está um detalhamento do Datee X-Cachestatus de vários acessos que fiz:

• 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

A razão pela qual existem vários itens com os mesmos dados exatos que estão Hit from cloudfrontpróximos do fim é porque é o que acontece em uma CDN: se o ponto final da CDN tiver o arquivo, ele se Datecorrelacionará com a data real de criação / modificação do arquivo que ponto final possui.

Você percebe que os quatro primeiros acessos estão separados por segundos, com datas / horas diferentes e todos eles Miss from cloudfront, certo? Isso significa que o terminal da CDN está apenas lembrando que houve uma tentativa de acessar esse arquivo naquele momento e todas as tentativas foram perdidas.

Portanto, minha avaliação da poltrona é que os sistemas do Tumblr não estão acompanhando o Amazon CloudFront CDN ou o Amazon CloudFront CDN não está acompanhando o Tumblr. Mas, de alguma forma, as coisas estão erradas no lado do servidor. E, como se trata de uma CDN, alguém que acessa os arquivos em um local pode não perceber um problema, enquanto alguém em outro local tem problemas para visualizar a imagem.

O que é tudo a dizer, eu não acho que isso possa ser facilmente esclarecido no lado do cliente.

EDIT: Então, o pôster original adicionou alguns novos URLs, e isso ainda aponta para um problema no servidor, mas eu só queria postar os detalhes para o registro.

EdgeCast & Highwinds CDN Ideas

Portanto, o pôster original adicionou mais detalhes. Aqui estão mais detalhes com base na postagem do blog que está sendo usada como exemplo:

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

E esses URLs de imagem são fornecidos como exemplos de URLs nessa postagem:

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

E esses dois URLs de imagem realmente falham. Mas do meu lado - olhando para o código de soure original da postagem do blog de Brooklyn, Nova York, EUA - não estou vendo esses gs1.wac.edgecastcdn.netURLs do EdgeCast ( ). Em vez disso, esses são os URLs que estou vendo:

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

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

Então, meu primeiro pensamento é por que o pôster original está vendo aqueles EdgeCast ( gs1.wac.edgecastcdn.net). Mas se eu fizer um traceroute para o 41.media.tumblr.comque vejo, é um servidor gerenciado pelo Highwinds (!?!?). Por outro lado, os URLs iniciais transmitidos pelo usuário original estão usando o 36.media.tumblr.comnome do host e você pode ver que eles são gerenciados pelos servidores Amazon CloudFront CDN.

O que é tudo a dizer - o que eu disse antes - tudo isso parece ser um problema do lado do servidor no Tumblr e no gerenciamento da CDN. Mas, do meu lado - no Brooklyn, Nova York, EUA -, vejo claramente o conteúdo sendo entregue conforme o esperado dos servidores Highwinds CDN e dos servidores Amazon CloudFront CDN. A origem desses URLs do EdgeCast ou como / por que eles estão falhando está fora do controle de qualquer pessoa no lado do cliente. Definitivamente, seria algo para entrar em contato com a equipe técnica do Tumblr, porque não há como um usuário final de desktop resolver isso.

Idéias de sanguessuga de imagem

Pode não ser mais relevante, mas aqui para referência.

Você afirmando isso me dá uma pista:

O uso wgetdos links diretos das imagens funciona.

Muitos sites têm regras em vigor - geralmente definidas via Apache - que impedem a ocorrência de imagens. Mais detalhes sobre como essas regras funcionam são fornecidos aqui e são resumidos da seguinte forma:

Usando .htaccess, você pode proibir a vinculação a quente no servidor, para que as tentativas de vincular a uma imagem ou arquivo CSS em seu site, por exemplo, sejam bloqueadas (falha na solicitação, como uma imagem quebrada) ou exibam um conteúdo diferente ( ou seja: a imagem de um homem revoltado).

Com base na sua descrição - e no fato de que você pode acessar as imagens via wget- me leva a acreditar que as imagens com as quais você está tendo problemas não são hospedadas no Tumblr pelos usuários, mas sim imagens que são colocadas em um blog do Tumblr, mas na verdade hospedadas em outro local.

Quando os procedimentos padrão de sanguessuga de imagem são implementados, a visualização de uma imagem incorporada em um site hospedado em outro site - que bloqueia a sanguessuga - resultaria em um link de imagem quebrado ou talvez em um "Stop Leeching!" imagem sendo retornada. Isso ocorre porque regras básicas anti-sanguessuga - como as da página de exemplo - fazem uma verificação cruzada dos referenciadores de imagem para garantir que a página que solicita a imagem corresponda ao domínio que hospeda a imagem.

Então, quando você está acessando a imagem via, wgetestá acessando a imagem diretamente. Portanto, as regras de leitura de imagens não são ativadas. Assim, você pode obter a imagem via, wgetmas não quando ela é incorporada em outra página.

Atualmente, estou tendo esse mesmo problema. Este é um exemplo seguro de trabalho - bem, é uma história em quadrinhos boba - de um blog afetado .

Se encontrado, no entanto, que o problema aconteceu apenas no Chrome para mim. Depois de um tempo, percebi que a causa do problema era a extensão " HTTPS em todos os lugares ". Quando o instalei no Firefox, tive o mesmo problema lá também. E, na verdade, se eu desativar a regra HTTPS "Tumblr (parcial)" (o que eu acho que significa *.tumblr.com), ela funcionará bem novamente.

Portanto, o problema parece ser que, pelo menos algumas vezes , quando o HTTPS é usado para acessar uma imagem, você é redirecionado para um URL do EdgeCast inválido. Por exemplo, este URL da imagem funciona bem:

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

Mas se você alterar o protocolo de httppara httpsvocê será redirecionado para este URL, o que não funcionará:

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

Não tenho certeza se isso conta como um erro do lado do Tumblr ou não. Eu acho que se os clientes não devem acessar seus servidores de mídia com HTTPS, você realmente não pode culpá-los por isso.

Edição: E, na verdade, o problema parece ter sido tratado como relatado neste segmento do GitHub .

Percebi esse comportamento mais na minha operadora de celular, a T-Mobile. Eu estou pensando que isso é algum tipo de modelagem de tráfego com base no tamanho da imagem ou em alguma operadora construída com "métricas de dificuldade" ao reformar o referido item.

Nos testes anteriores - há mais de um ano -, compartilhei a postagem com um amigo que tenha a Verizon, e a imagem carrega bem.

Embora eu não possa testar essa imagem, estou prestes a fornecer - como meu amigo não está disponível - essa imagem não carrega para mim. Estou executando o Android (5.0.1) em um Nexus 5 usando o Chrome como navegador.

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

Quando tento carregar a imagem diretamente, recebo um erro de tempo limite do gateway 504.

EDIT: Este é @JakeGould postando a imagem real para referência.

Testes e detalhes adicionais: estou em Baltimore MD, sem dados do LTE e a seguinte imagem funcionou: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

Testes adicionais mostram que o PNG não parece ser o problema. A maioria das outras imagens que funcionei foram uma mistura de png e jpg, mas todas estavam em servidores não "41".

Nota final: cheguei em casa, entrei no meu wifi -Comcast- com o meu telefone - o dispositivo em que eu estava testando- e todas as fotos que não pude ver devido ao 504 que agora posso ver.

EDIT: Novo no superusuário, post cortado e editado, por isso foi mais factual e menos discussão.

ATUALIZAÇÃO: o problema parece estar vinculado ao LTE. Carreguei o Tumblr, encontrei algumas imagens que não carregavam, forçou meu telefone a 3G, página recarregada, todas as imagens são exibidas. O telefone foi revertido para o LTE, o cache limpo e as imagens que não eram carregadas anteriormente no LTE agora são carregadas.
(Estou testando novamente e agora não consigo reproduzir. Talvez o comportamento acima tenha sido um acaso.)