Mengapa gambar dari beberapa halaman Tumblr tidak dimuat, tetapi menggunakan wget berfungsi?

Membantu seorang teman dengan koneksi internet mereka karena "beberapa halaman tidak akan memuat", saya perhatikan bahwa masalahnya adalah bahwa gambar posting gambar blog tertentu tidak dimuat di browser. Saya merasa aneh karena alasan berikut:

1. Hanya gambar yang merupakan bagian dari pos tidak akan dimuat. Avatar pengguna, spanduk, tajuk, berbagai tema dan / atau gambar yang berhubungan dengan halaman masih muncul.
2. Terjadi dengan browser apa pun di komputer (Diuji pada Firefox dan Chrome / ium baik dengan dan tanpa pemblokir iklan / skrip).
3. Menggunakan wgettautan langsung pada gambar berfungsi.
4. Ini tidak berlaku untuk semua halaman Tumblr. Sebagian memuat dengan benar, tetapi ketika membuat daftar halaman dengan posting yang tidak memuat gambar menunjukkan bahwa mereka sebagian besar dari sekelompok pengguna yang sama.
5. Masalahnya tampaknya khusus blog dalam arti bahwa jika posting gambar blog tertentu tidak dimuat di browser, blog lain (tidak terpengaruh atau tidak) yang me-reblog posting yang sama tidak akan memuat gambar di browser juga. Sebaliknya, jika blog yang terpengaruh adalah reblog dari blog yang tidak terpengaruh, gambar akan dimuat dengan baik.
6. Gambar-gambar tersebut berasal dari pos Tumblr yang dibuat pengguna tempat pengguna mengunggah gambar untuk dikirim dan di-host oleh Tumblr. Misalnya (contoh ini bukan salah satu blog yang terpengaruh), dalam posting gambar ini (dipilih secara acak), ini akan menjadi tautan langsung ke gambar dalam posting. Posting gambar secara otomatis membuat gambar tautan ke halaman lain di Tumblr menggunakan (biasanya) versi gambar yang lebih besar yang digunakan dalam posting yang lebih dekat dengan ukuran yang diunggah pengguna untuk posting tersebut.

Apa yang mungkin menjadi alasan terjadinya hal ini? Bagian yang benar-benar membuat saya adalah fakta yang wgetberfungsi, jadi saya pikir saya bisa berasumsi bahwa itu bukan masalah dengan koneksi jaringan.

Memperbarui:

Ini adalah contoh dari postingan yang telah di-reblog yang gagal dimuat di browser. The blog utama memiliki posting gambar lain yang memuat dengan benar. Ini adalah tautan langsung ke gambar di pos dan di sini adalah untuk versi yang lebih besar (keduanya tidak memuat di sini). wgetberfungsi untuk keduanya, tetapi saat membuka tautan langsung apa pun dengan Firefox, kesalahan ini muncul:

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>

RequestIDdan HostIdberubah setiap saat. Teman saya dan saya berlokasi di Filipina.

Perbarui [2014/03/08]

Setelah pengujian lebih lanjut dan membalas email dukungan Tumblr, wgettelah berhenti bekerja (mendapatkan 403 kesalahan pada tautan langsung) pada beberapa kesempatan.

Perbarui [2014/03/09]

Mematikan aturan Tumblr untuk HTTPS-Everywhere sepertinya terkadang memperbaiki masalah.

_catatan:

• _{Dalam contoh untuk # 6, tautan langsung keduanya mengarah ke gambar yang sama. Namun, biasanya yang digunakan dalam posting gambar (dibandingkan dengan halaman gambar yang dapat diperbesar) menggunakan versi gambar yang lebih kecil agar sesuai dengan tema halaman. Contohnya menggunakan tema yang dibuat untuk layar yang lebih besar sehingga tidak perlu versi yang lebih kecil.}

PEMBARUAN: Tampaknya masalah inti dengan gambar yang tidak dimuat berasal dari cara HTTPS Everywhere plugin / ekstensi menangani beberapa URL Tumblr. Pengembang telah diberi tahu dan tampaknya ada perbaikan . Jawaban ini pada dasarnya memecah pekerjaan detektif yang dilakukan untuk mengungkap masalah sebagaimana dijabarkan oleh pertanyaan awal dan dapat terbukti bermanfaat untuk debugging / diagnosis lebih lanjut jika masalah serupa muncul di masa depan.

EDIT: Konten yang lebih besar tentang lintah gambar tampaknya tidak valid. Jadi akan menambahkan ide baru di bagian atas dan meninggalkan info lintah gambar di bagian bawah kalau-kalau itu berguna untuk seseorang.

Amazon CloudFront CDN Ideas

Oke, dengan menggunakan URL yang Anda berikan — juga beberapa pengalaman dunia nyata saya dengan pengaturan CDN Amazon CloudFront — saya pikir saya menemukan sesuatu. Sepertinya konfigurasi Tumblr Amazon CloudFront CDN tersedak karena beberapa alasan. Inilah sebabnya saya pikir itulah masalahnya.

Mari kita ambil contoh URL ini:

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

Sekarang mari kita jalankan curl -Iuntuk mendapatkan informasi header pada file itu:

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

Output untuk itu akan menjadi seperti ini:

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

Sekarang hal-hal yang perlu diperhatikan di sini adalah header Date(tanggal dan waktu file pada titik akhir CloudFront) dan X-Cache(status pengiriman konten Amazon). Perilaku khas di Amazon CloudFront adalah akses pertama akan menyampaikan "Miss from cloudfront" dan kemudian jika Anda melakukan yang lain curl -Isegera setelah itu harus ada Hit from cloudfront.

Tapi bukan itu yang saya lihat tadi. Berikut ini rincian Datedan X-Cachestatus sekelompok akses yang saya buat:

• 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

Alasan mengapa ada banyak item dengan data yang persis sama yang Hit from cloudfrontmendekati akhir adalah karena itulah yang terjadi pada CDN: Jika titik akhir CDN memiliki file, maka Dateberkorelasi dengan tanggal pembuatan / modifikasi aktual file yang titik akhir memiliki.

Anda perhatikan empat akses pertama terpisah beberapa detik, dengan tanggal / waktu yang berbeda dan semuanya Miss from cloudfront, kan? Itu berarti titik akhir CDN hanya menggema kembali bahwa ada upaya untuk mengakses file pada waktu itu dan semua upaya gagal.

Jadi penilaian kursi saya tentang hal ini adalah bahwa sistem Tumblr tidak mengikuti CDN Amazon CloudFront atau Amazon CloudFront CDN tidak mengikuti Tumblr. Tetapi dalam beberapa hal, ada yang salah di sisi server mereka. Dan karena ini adalah CDN, seseorang yang mengakses file di satu lokasi mungkin tidak melihat masalah sementara orang lain di lokasi lain akan mengalami masalah melihat gambar.

Yang bisa dikatakan, saya tidak berpikir ini dapat dengan mudah diselesaikan di sisi klien.

EDIT: Jadi poster asli menambahkan beberapa URL baru, dan ini masih menunjuk ke masalah sisi server, tapi saya hanya ingin memposting rincian untuk catatan.

EdgeCast & Highwinds Ide CDN

Jadi poster asli menambahkan lebih spesifik, jadi di sini lebih detail berdasarkan posting blog yang digunakan sebagai contoh:

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

Dan URL gambar ini disediakan sebagai contoh URL dalam posting itu:

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

Dan kedua URL gambar itu memang gagal. Tapi dari sisi saya — melihat kode sumber asli dari posting blog dari Brooklyn, New York, AS — saya tidak melihat gs1.wac.edgecastcdn.netURL EdgeCast ( ) itu. Sebaliknya, ini adalah URL yang saya lihat:

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

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

Jadi pemikiran pertama saya adalah mengapa poster asli melihat EdgeCast tersebut ( gs1.wac.edgecastcdn.net). Tetapi kemudian jika saya melakukan traceroute ke 41.media.tumblr.comSaya melihat itu adalah server yang dikelola oleh Highwinds (!?!?). Sebaliknya, URL awal yang diteruskan oleh pengguna asli menggunakan 36.media.tumblr.comnama host dan Anda dapat melihatnya dikelola oleh server Amazon CloudFront CDN.

Yang bisa dikatakan - yang saya katakan sebelumnya - semua ini tampaknya merupakan masalah sisi server dengan Tumblr dan manajemen CDN mereka. Tetapi dari pihak saya — di Brooklyn, New York, AS — saya dengan jelas melihat konten dikirimkan seperti yang diharapkan dari server Highwinds CDN dan juga server Amazon CloudFront CDN. Dari mana URL EdgeCast ini berasal atau bagaimana / mengapa URL itu gagal berada di luar kendali siapa pun di sisi klien. Ini pasti akan menjadi sesuatu untuk dihubungi staf teknologi Tumblr karena tidak ada cara pengguna desktop dapat menyelesaikan ini.

Ide Leeching Gambar

Mungkin tidak relevan lagi, tetapi di sini untuk referensi.

Anda menyatakan ini beri saya petunjuk:

Menggunakan wgettautan langsung pada gambar berfungsi.

Banyak situs memiliki aturan - biasanya ditetapkan melalui Apache - yang mencegah lintah gambar. Rincian lebih lanjut tentang cara kerja aturan tersebut disediakan di sini dan diringkas sebagai berikut:

Menggunakan .htaccess, Anda dapat melarang tautan panas di server Anda, jadi mereka yang mencoba menautkan ke gambar atau file CSS di situs Anda, misalnya, diblokir (permintaan gagal, seperti gambar yang rusak) atau menyajikan konten yang berbeda ( yaitu: gambar pria yang marah).

Berdasarkan uraian Anda — dan fakta bahwa Anda dapat mengakses gambar melalui wget—membimbing saya untuk percaya bahwa gambar yang Anda hadapi tidak di-host di Tumblr oleh pengguna, melainkan gambar yang ditempatkan di blog Tumblr tetapi sebenarnya di-host pada yang lain situs

Ketika prosedur lintah gambar standar diberlakukan, melihat gambar tertanam di satu situs yang di-host di situs lain-yang memblokir lintah-akan menghasilkan tautan gambar yang rusak atau mungkin "Stop Leeching!" gambar dikembalikan. Ini karena aturan dasar anti-lintah — seperti yang ada di halaman contoh tersebut — periksa kembali perujuk gambar untuk memastikan bahwa laman yang meminta gambar cocok dengan domain yang menampung gambar.

Jadi ketika Anda mengakses gambar melalui wgetAnda mengakses gambar secara langsung. Jadi aturan lintah gambar tidak akan masuk. Dengan demikian Anda bisa mendapatkan gambar melalui wgettetapi tidak ketika itu tertanam di halaman lain.

Saat ini saya sedang mengalami masalah ini. Ini aman untuk bekerja — yah ini komik konyol — contoh blog yang terpengaruh .

Namun jika ternyata masalahnya hanya terjadi di Chrome untuk saya. Setelah beberapa saat, saya menyadari bahwa penyebab masalah ini adalah ekstensi " HTTPS Everywhere ." Ketika saya menginstalnya di Firefox, saya juga memiliki masalah yang sama. Dan sebenarnya, jika saya menonaktifkan aturan HTTPS "Tumblr (sebagian)" (yang saya kira artinya *.tumblr.com), itu berfungsi dengan baik lagi.

Jadi, masalahnya adalah bahwa, setidaknya kadang-kadang , ketika HTTPS digunakan untuk mengakses gambar, Anda dialihkan ke URL EdgeCast yang tidak valid. Misalnya, URL gambar ini berfungsi dengan baik:

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

Tetapi jika Anda mengubah protokol dari httpke httpsAnda akan diarahkan ke URL ini yang tidak berfungsi:

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

Saya tidak yakin apakah ini dianggap sebagai kesalahan dari sisi Tumblr atau tidak. Saya kira jika klien tidak seharusnya mengakses server media mereka dengan HTTPS, Anda tidak dapat menyalahkan mereka karenanya.

EDIT: Dan sebenarnya masalahnya sepertinya telah diatasi seperti yang dilaporkan dalam utas GitHub ini .

Saya lebih memperhatikan perilaku ini saat menggunakan operator seluler saya, T-Mobile. Saya pikir ini semacam pembentuk lalu lintas berdasarkan ukuran gambar atau "metrik tingkat kesulitan" yang dibuat oleh operator dalam retreaving item tersebut.

Dalam pengujian sebelumnya — lebih dari setahun yang lalu — saya kemudian membagikan pos yang rusak kepada seorang teman yang memiliki Verizon, dan gambarnya dimuat dengan baik.

Meskipun saya tidak dapat menguji gambar ini, saya akan menyediakan — karena teman saya tidak tersedia — gambar ini tidak memuat untuk saya. Saya menjalankan stock Android (5.0.1) pada Nexus 5 menggunakan Chrome sebagai browser.

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

Ketika saya mencoba memuat gambar secara langsung, saya mendapatkan 504 gateway timeout error.

EDIT: Ini adalah @JakeGould memposting gambar yang sebenarnya untuk referensi.

Pengujian dan perincian lebih lanjut: Saya di Baltimore MD, kehabisan data LTE dan gambar berikut berhasil: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

Pengujian lebih lanjut menunjukkan bahwa PNG tampaknya tidak menjadi masalah. Sebagian besar gambar lain yang saya tekan yang berfungsi adalah campuran png dan jpg, tetapi semua berada di server non "41".

Catatan akhir: Saya sampai di rumah, melompat di wifi saya -Comcast- dengan ponsel saya -perangkat yang telah saya uji- dan semua foto yang tidak bisa saya lihat karena 504 sekarang bisa saya lihat.

EDIT: Baru untuk pengguna super, dipangkas dan diedit sehingga lebih faktual dan kurang diskusi.

PEMBARUAN: Masalah tampaknya terkait dengan LTE. Memuat tumblr, menemukan beberapa gambar yang tidak mau memuat, memaksa ponsel saya ke 3g, halaman dimuat, semua gambar ditampilkan. Ponsel yang dikembalikan ke LTE, cache yang dihapus, dan gambar-gambar yang sebelumnya tidak dimuat di bawah LTE sekarang memuat.
(Saya menguji lagi dan sekarang saya tidak dapat mereproduksi. Jadi mungkin perilaku di atas adalah kebetulan.)