Perché le immagini di alcune pagine di Tumblr non vengono caricate, ma l'utilizzo di wget su di esse funziona?

Aiutando un amico con la sua connessione a Internet perché "alcune pagine non si caricano", ho notato che il problema era che le immagini dei post delle immagini di alcuni blog non venivano caricate sul browser. L'ho trovato strano per i seguenti motivi:

1. Solo le immagini che fanno parte del post non verranno caricate. Vengono comunque visualizzati avatar dell'utente, banner, intestazioni, vari temi e / o immagini relative alla pagina.
2. Succede con qualsiasi browser sul computer (testato su Firefox e Chrome / ium sia con che senza blocco annunci / script).
3. L'uso wgetdei collegamenti diretti delle immagini funziona.
4. Questo non si applica a tutte le pagine di Tumblr. La maggior parte viene caricata correttamente, ma quando si crea un elenco di pagine con post che non caricano immagini mostra che provengono principalmente dallo stesso gruppo di utenti.
5. Il problema sembra essere specifico del blog, nel senso che se il post di un'immagine di un determinato blog non viene caricato nel browser, altri blog (non interessati o meno) che includevano lo stesso post non caricheranno l'immagine nel browser. Viceversa, se un blog interessato si discosta da uno non interessato, l'immagine si carica bene.
6. Le immagini provengono da post di Tumblr creati dall'utente in cui l'utente carica un'immagine da pubblicare e sono ospitati da Tumblr. Ad esempio (questo esempio non è uno dei blog interessati), in questo post di immagine (selezionato casualmente), questo sarebbe il collegamento diretto all'immagine nel post. I post delle immagini rendono automaticamente le immagini un collegamento a un'altra pagina in Tumblr utilizzando una versione (solitamente) più grande dell'immagine utilizzata nel post che è più vicina alla dimensione di ciò che l'utente ha caricato per il post.

Quale può essere la ragione per cui questo accade? La parte che mi prende davvero è il fatto che wgetfunziona, quindi penso di poter presumere che non sia un problema con la connessione di rete.

Aggiornare:

Ecco un esempio di post pubblicato che non viene caricato sui browser. Il blog principale ha altri post di immagini che si caricano correttamente. Questo è il link diretto all'immagine nel post ed ecco quello per la versione più grande (entrambi non si caricano qui). wgetfunziona per entrambi, ma quando si accede a un collegamento diretto con Firefox, viene visualizzato questo errore:

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 HostIdcambia ogni volta. Io e il mio amico siamo nelle Filippine.

Aggiornamento [2014/03/08]

Dopo ulteriori test e la risposta alle e-mail del supporto Tumblr, wgetha smesso di funzionare (ricevendo 403 errori sui collegamenti diretti) in alcune occasioni.

Aggiornamento [2014/03/09]

Disattivare le regole di Tumblr per HTTPS-Everywhere sembra a volte risolvere il problema.

_Nota:

• _{Nell'esempio per # 6, entrambi i collegamenti diretti puntano alla stessa immagine. Di solito, tuttavia, quello utilizzato nel post dell'immagine (rispetto alla pagina dell'immagine ingrandibile) utilizza una versione più piccola dell'immagine per adattarsi al tema della pagina. L'esempio usa un tema creato per schermi più grandi, quindi non ha bisogno della versione più piccola.}

AGGIORNAMENTO: Sembra che il problema principale con le immagini non caricate sia derivato dal modo in cui il plugin / estensione HTTPS Everywhere di EFF ha gestito alcuni URL di Tumblr. Lo sviluppatore è stato informato e una soluzione sembra essere in atto . Questa risposta sostanzialmente interrompe il lavoro investigativo svolto per scoprire il problema come indicato dalla domanda iniziale e potrebbe rivelarsi utile per un ulteriore debug / diagnosi se in futuro dovesse apparire un problema simile.

EDIT: il contenuto più ampio sulla sanguisuga delle immagini sembra non valido. Quindi aggiungerò una nuova idea in alto e lasceremo le informazioni sulla sanguisuga in basso nel caso in cui sia utile a qualcuno.

Idee CDN Amazon CloudFront

Bene, usando gli URL che hai fornito, così come alcune delle mie esperienze nel mondo reale con le configurazioni CDN di Amazon CloudFront, penso di aver scoperto qualcosa. Sembra che Amazon CloudFront CDN config sia soffocato per qualche motivo. Ecco perché penso che sia così.

Prendiamo questo URL di esempio:

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

Ora corriamo curl -Iper ottenere informazioni di intestazione su quel file:

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

L'output per questo sarebbe qualcosa del genere:

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

Ora le cose a cui prestare attenzione qui sono le intestazioni Date(la data e l'ora del file sull'endpoint CloudFront) e X-Cache(stato di consegna del contenuto Amazon). Il comportamento tipico su Amazon CloudFront è che il primo accesso trasmetterà una "Miss da cloudfront" e quindi se ne fai curl -Isubito un altro dopo dovrebbe esserci un Hit from cloudfront.

Ma non è quello che ho visto proprio ora. Ecco una ripartizione dello stato Datee X-Cachedi un gruppo di accessi che ho effettuato:

• 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

Il motivo per cui ci sono più elementi con gli stessi dati esatti Hit from cloudfrontvicini alla fine è perché questo è ciò che accade su un CDN: se l'endpoint del CDN ha il file, allora è Datecorrelato alla data di creazione / modifica effettiva del file che l'endpoint ha.

Notate che i primi quattro accessi sono distanti pochi secondi, con date / orari diversi e tutti sono Miss from cloudfront, giusto? Ciò significa che l'endpoint della CDN sta semplicemente facendo eco che si è verificato un tentativo di accedere a quel file in quel momento e tutti i tentativi sono stati falliti.

Quindi la mia valutazione da parte della poltrona è che i sistemi di Tumblr non stanno al passo con la CDN di Amazon CloudFront o che la CDN di Amazon CloudFront non sta al passo con Tumblr. Ma in qualche modo, le cose vanno male sul loro lato server. E poiché si tratta di una CDN, qualcuno che accede ai file in una posizione potrebbe non notare un problema mentre qualcun altro in un'altra posizione avrebbe problemi a visualizzare l'immagine.

Il che è tutto da dire, non credo che questo possa essere chiarito facilmente sul lato client.

EDIT: Quindi il poster originale ha aggiunto alcuni nuovi URL, e questo indica ancora un problema sul lato server, ma volevo solo pubblicare i dettagli per il record.

EdgeCast & Highwinds Idee CDN

Quindi il poster originale ha aggiunto ulteriori dettagli, quindi qui ci sono più dettagli basati sul post del blog che viene utilizzato come esempio:

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

E questi URL di immagini sono forniti come esempi di URL in quel 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

E quei due URL di immagini falliscono davvero. Ma dalla mia parte, guardando il codice soure originale del post sul blog di Brooklyn, New York, USA, non vedo quegli gs1.wac.edgecastcdn.netURL EdgeCast ( ). Piuttosto, questi sono gli URL che sto vedendo:

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

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

Quindi il mio primo pensiero è perché il poster originale vede EdgeCast ( gs1.wac.edgecastcdn.net). Ma poi se faccio un traceroute al 41.media.tumblr.comvedo che è un server gestito da Highwinds (!?!?). Al contrario, gli URL iniziali trasmessi dall'utente originale utilizzano il 36.media.tumblr.comnome host e puoi vedere che sono gestiti dai server CDN di Amazon CloudFront.

Il che è tutto da dire — che ho detto prima — tutto questo sembra essere un problema lato server con Tumblr e la loro gestione della CDN. Ma dalla mia parte - a Brooklyn, New York, Stati Uniti - vedo chiaramente i contenuti distribuiti come previsto dai server CDN di Highwinds e dai server CDN di Amazon CloudFront. Da dove provengono questi URL EdgeCast o come / perché falliscono è fuori dal controllo di chiunque sul lato client. Questo sarebbe sicuramente qualcosa su cui contattare il personale tecnico di Tumblr perché non c'è modo che un utente finale desktop possa risolverlo.

Idee per le sanguisughe di immagini

Potrebbe non essere più pertinente, ma qui per riferimento.

Mi stai dicendo che mi dai un indizio:

L'uso wgetdei collegamenti diretti delle immagini funziona.

Molti siti hanno regole in atto - di solito impostate tramite Apache - che impediscono il sanguinamento delle immagini. Maggiori dettagli su come funzionano tali regole sono forniti qui e sono riassunti come segue:

Utilizzando .htaccess, puoi impedire il collegamento a caldo sul tuo server, quindi coloro che tentano di collegarsi a un'immagine o un file CSS sul tuo sito, ad esempio, vengono bloccati (richiesta non riuscita, come un'immagine interrotta) o offerti un contenuto diverso ( cioè: un'immagine di un uomo arrabbiato).

In base alla tua descrizione, e al fatto che puoi accedere alle immagini tramite, wgetmi spinge a credere che le immagini con cui stai riscontrando problemi non sono ospitate su Tumblr dagli utenti, ma piuttosto immagini che sono collocate su un blog Tumblr ma effettivamente ospitate su un altro luogo.

Quando vengono messe in atto procedure standard di sanguisuga delle immagini, la visualizzazione di un'immagine incorporata su un sito ospitato su un altro sito, che blocca le sanguisughe, si tradurrebbe in un collegamento di immagine interrotto o forse in un "Stop Leeching!" immagine restituita. Questo perché le regole anti-sanguisuga di base, come quelle in quella pagina di esempio, controllano i referrer di immagini per assicurarsi che la pagina che richiede l'immagine corrisponda al dominio che ospita l'immagine.

Quindi quando si accede all'immagine tramite wgetsi accede direttamente all'immagine. Quindi le regole di sanguisuga delle immagini non entrerebbero in gioco. In questo modo è possibile ottenere l'immagine tramite wgetma non quando è incorporata in un'altra pagina.

Attualmente sto avendo questo problema. Questo è sicuro per il lavoro - beh, è ​​un fumetto sciocco - esempio di blog interessato .

Se trovato, tuttavia, che il problema si è verificato solo in Chrome per me. Dopo un po 'mi sono reso conto che la causa del problema era l'estensione " HTTPS Everywhere ". Quando l'ho installato in Firefox, ho avuto lo stesso problema anche lì. E in realtà, se disabilito la regola HTTPS "Tumblr (parziale)" (che immagino significhi *.tumblr.com), funziona di nuovo bene.

Quindi, il problema sembra essere che, almeno a volte , quando HTTPS viene utilizzato per accedere a un'immagine, si viene reindirizzati a un URL EdgeCast non valido. Ad esempio, questo URL immagine funziona correttamente:

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

Ma se si modifica il protocollo da httpa httpssi viene reindirizzati a questo URL che non funziona:

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

Non sono sicuro che ciò valga come errore dal lato Tumblr o no. Immagino che se i client non dovessero accedere ai loro media server con HTTPS, non si può davvero biasimarli.

EDIT: E in realtà il problema sembra essere stato risolto come riportato in questo thread GitHub .

Ho notato questo comportamento di più mentre sul mio operatore di telefonia mobile, T-Mobile. Sto pensando che si tratti di una sorta di modellamento del traffico basato sulla dimensione dell'immagine o su qualche "metrica di difficoltà" creata dal corriere per la ricostruzione di detto articolo.

Nei test precedenti, più di un anno fa, ho condiviso il post non funzionante con un amico che ha Verizon e l'immagine si carica bene.

Anche se non riesco a testare questa immagine, sto per fornire, poiché il mio amico non è disponibile, questa immagine non viene caricata per me. Sto eseguendo Android (5.0.1) su un Nexus 5 usando Chrome come browser.

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

Quando provo a caricare l'immagine direttamente ottengo un errore di timeout del gateway 504.

EDIT: Questo è @JakeGould che pubblica l'immagine reale come riferimento.

Ulteriori test e dettagli: sono a Baltimora MD, sto esaurendo i dati LTE e la seguente immagine ha funzionato: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

Ulteriori test dimostrano che PNG non sembra essere il problema. La maggior parte delle altre immagini che ho funzionato erano un mix di png e jpg, ma tutte erano su server non "41".

Nota finale: sono tornato a casa, ho acceso il mio wifi -Comcast- con il mio telefono -il dispositivo sul quale ho testato- e tutte le foto che non potevo vedere a causa di 504 che ora posso vedere.

EDIT: Nuovo per post superutente, rifilato e modificato, quindi era più fattuale e meno discussione.

AGGIORNAMENTO: il problema sembra essere legato a LTE. Caricato su Tumblr, ho trovato alcune immagini che non si sarebbero caricate, hanno costretto il mio telefono a 3g, ricaricato la pagina, tutte le immagini mostrano. Ripristino del telefono su LTE, svuotamento della cache e caricamento delle immagini che in precedenza non erano caricate su LTE.
(Sto testando di nuovo e ora non riesco a riprodurre. Quindi forse il comportamento sopra è stato un colpo di fortuna.)