ทำไมรูปภาพจากหน้า Tumblr บางหน้าถึงไม่โหลด แต่การใช้ wget กับพวกมันทำงานได้ดี?

ช่วยเพื่อนออกด้วยการเชื่อมต่ออินเทอร์เน็ตเพราะ“ บางหน้าไม่โหลด” ฉันสังเกตเห็นว่าปัญหาคือรูปภาพของโพสต์ภาพบางบล็อกไม่ได้โหลดบนเบราว์เซอร์ ฉันพบว่ามันแปลกเพราะเหตุผลดังต่อไปนี้:

1. รูปภาพที่เป็นส่วนหนึ่งของโพสต์จะไม่โหลด อวตารของผู้ใช้แบนเนอร์ส่วนหัวชุดรูปแบบต่างๆและ / หรือรูปภาพที่เกี่ยวข้องกับหน้ายังคงปรากฏขึ้น
2. เกิดขึ้นกับเบราว์เซอร์ใด ๆ บนคอมพิวเตอร์ (ทดสอบบน Firefox และ Chrome / ium ทั้งที่มีและไม่มีตัวบล็อกโฆษณา / สคริปต์)
3. ใช้wgetงานลิงค์โดยตรงของภาพได้
4. สิ่งนี้ใช้ไม่ได้กับหน้า Tumblr ทั้งหมด โหลดอย่างถูกต้องที่สุด แต่เมื่อสร้างรายการหน้าเว็บที่มีโพสต์ที่ไม่โหลดรูปภาพแสดงว่าส่วนใหญ่มาจากกลุ่มผู้ใช้เดียวกัน
5. ดูเหมือนว่าปัญหาจะมีเฉพาะบล็อกในแง่ที่ว่าหากโพสต์รูปภาพบางบล็อกไม่โหลดในเบราว์เซอร์บล็อกอื่น ๆ (ไม่ได้รับผลกระทบหรือไม่) ที่บล็อกใหม่โพสต์เดียวกันจะไม่โหลดภาพในเบราว์เซอร์เช่นกัน ในทางกลับกันหากบล็อกที่ได้รับผลกระทบถูกบล็อกซ้ำจากบล็อกที่ไม่ได้รับผลกระทบภาพจะโหลดได้ดี
6. รูปภาพมาจากโพสต์ Tumblr ที่ผู้ใช้สร้างขึ้นซึ่งผู้ใช้อัปโหลดภาพไปยังโพสต์และโฮสต์โดย Tumblr ตัวอย่างเช่น (ตัวอย่างนี้ไม่ใช่หนึ่งในบล็อกที่ได้รับผลกระทบ) ในโพสต์ภาพ (เลือกแบบสุ่ม) นี่จะเป็นลิงก์โดยตรงไปยังรูปภาพในโพสต์ โพสต์รูปภาพทำให้รูปภาพเชื่อมโยงไปยังหน้าอื่นใน Tumblrโดยอัตโนมัติ (โดยปกติ) รูปภาพขนาดใหญ่ที่ใช้ในโพสต์ที่ใกล้เคียงกับขนาดของสิ่งที่ผู้ใช้อัปโหลดสำหรับโพสต์

อะไรคือสาเหตุของเหตุการณ์นี้ ส่วนที่ทำให้ฉันจริง ๆ คือความจริงที่ใช้wgetงานได้ดังนั้นฉันคิดว่าฉันสามารถสันนิษฐานได้ว่าไม่มีปัญหากับการเชื่อมต่อเครือข่าย

ปรับปรุง:

นี่คือตัวอย่างของโพสต์ที่ถูกบล็อกใหม่ซึ่งไม่สามารถโหลดบนเบราว์เซอร์ได้ บล็อกหลักมีการโพสต์ภาพอื่น ๆ ที่โหลดอย่างถูกต้อง นี่คือลิงก์โดยตรงไปยังรูปภาพในโพสต์และนี่คือลิงค์สำหรับเวอร์ชันที่ใหญ่กว่า (ทั้งคู่ไม่โหลดที่นี่) wgetใช้ได้กับทั้งคู่ แต่เมื่อไปที่ลิงก์โดยตรงกับ Firefox ข้อผิดพลาดนี้จะปรากฏขึ้น:

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และHostIdการเปลี่ยนแปลงทุกครั้ง เพื่อนของฉันและฉันอยู่ที่ฟิลิปปินส์

อัปเดต [2014/03/08]

เมื่อทดสอบเพิ่มเติมและตอบกลับอีเมลของการสนับสนุน Tumblr wgetได้หยุดทำงาน (ได้รับข้อผิดพลาด 403 ลิงก์โดยตรง) ในบางโอกาส

อัปเดต [2014/03/09]

การปิดกฎ Tumblr สำหรับ HTTPS ทุกที่ในบางครั้งดูเหมือนว่าจะแก้ไขปัญหาได้

_{บันทึก:}

• _{ในตัวอย่างสำหรับ # 6 ลิงก์โดยตรงทั้งสองชี้ไปที่ภาพเดียวกัน อย่างไรก็ตามโดยปกติรูปภาพที่ใช้ในโพสต์ภาพ (เมื่อเทียบกับหน้ารูปภาพที่ซูมได้) จะใช้รูปภาพที่มีขนาดเล็กลงเพื่อให้สอดคล้องกับธีมของหน้า ตัวอย่างใช้ชุดรูปแบบที่สร้างขึ้นสำหรับหน้าจอขนาดใหญ่ดังนั้นจึงไม่จำเป็นต้องใช้รุ่นที่เล็กกว่า}

UPDATE:ดูเหมือนว่าปัญหาหลักของภาพที่ไม่ได้โหลดเกิดขึ้นจากวิธีที่ปลั๊กอิน / ส่วนขยาย HTTPS ทุกที่ของ EFFจัดการกับ Tumblr URL ของนักพัฒนาได้รับการแจ้งเตือนและการแก้ไขที่ดูเหมือนจะอยู่ในสถานที่ คำตอบนี้แบ่งการทำงานของนักสืบออกเพื่อเปิดเผยปัญหาตามที่ระบุไว้ในคำถามเริ่มต้นและสามารถพิสูจน์ได้ว่ามีประโยชน์สำหรับการดีบัก / วินิจฉัยเพิ่มเติมหากปัญหาที่คล้ายกันปรากฏขึ้นในอนาคต

แก้ไข:เนื้อหาขนาดใหญ่เกี่ยวกับการ leeching ภาพดูเหมือนไม่ถูกต้อง ดังนั้นจะเพิ่มความคิดใหม่ที่ด้านบนและปล่อยข้อมูล leeching ภาพที่ด้านล่างในกรณีที่เป็นประโยชน์กับใครบางคน

แนวคิด CDN ของ Amazon CloudFront

โอเคใช้ URL ที่คุณให้ไว้ - รวมถึงประสบการณ์การใช้งานจริงของฉันในการตั้งค่า CDN ของ Amazon CloudFront - ฉันคิดว่าฉันค้นพบบางสิ่ง ดูเหมือนว่าการกำหนดค่า Amazon CloudFront CDN ของ Tumblr กำลังสำลักด้วยเหตุผลบางประการ นี่คือเหตุผลที่ฉันคิดว่าเป็นอย่างนั้น

ลอง URL ตัวอย่างนี้:

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

ทีนี้ลองเรียกใช้curl -Iเพื่อรับข้อมูลส่วนหัวของไฟล์:

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

ผลลัพธ์สำหรับสิ่งนั้นจะเป็นดังนี้:

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

ตอนนี้สิ่งที่ต้องใส่ใจที่นี่คือส่วนหัวDate(วันที่และเวลาของไฟล์บนจุดสิ้นสุด CloudFront) และX-Cache(สถานะการส่งเนื้อหาของ Amazon) พฤติกรรมทั่วไปใน Amazon CloudFront คือการเข้าถึงแรกจะถ่ายทอด“มิสจาก CloudFront” แล้วถ้าคุณทำอีกทันทีหลังจากนั้นควรจะมีcurl -IHit from cloudfront

แต่นั่นไม่ใช่สิ่งที่ฉันเห็นในตอนนี้ นี่คือรายละเอียดของDateและX-Cacheสถานะของการเข้าถึงที่ฉันทำ:

• 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

เหตุผลที่มีหลายรายการที่มีข้อมูลที่แน่นอนเหมือนกันซึ่งHit from cloudfrontใกล้จะถึงจุดสิ้นสุดนั้นเป็นเพราะสิ่งที่เกิดขึ้นใน CDN: หากจุดสิ้นสุดของ CDN มีไฟล์อยู่นั้นDateมีความสัมพันธ์กับวันที่สร้าง / แก้ไขจริงของไฟล์ที่ จุดสิ้นสุดมี

คุณสังเกตเห็นว่าการเข้าถึงสี่ครั้งแรกนั้นแตกต่างกันโดยมีวันที่ / เวลาที่แตกต่างกันและการเข้าถึงทั้งหมดนั้นMiss from cloudfrontใช่ไหม? นั่นหมายความว่าจุดสิ้นสุด CDN เพิ่งสะท้อนกลับมาว่ามีความพยายามในการเข้าถึงไฟล์ดังกล่าวในเวลานั้นและความพยายามทั้งหมดพลาดไป

ดังนั้นการประเมินเก้าอี้ของฉันเกี่ยวกับเรื่องนี้ก็คือระบบของ Tumblr ไม่สอดคล้องกับ Amazon CloudFront CDN หรือ Amazon CloudFront CDN ไม่ได้ติดตาม Tumblr แต่อย่างใดสิ่งที่ไม่เหมาะสมในฝั่งเซิร์ฟเวอร์ของพวกเขา และเนื่องจากนี่คือ CDN ใครบางคนที่เข้าถึงไฟล์ในตำแหน่งเดียวอาจไม่สังเกตเห็นปัญหาในขณะที่คนอื่นในตำแหน่งอื่นจะมีปัญหาในการดูรูปภาพ

ซึ่งก็คือทั้งหมดนี้ฉันไม่คิดว่ามันจะถูกลบล้างได้อย่างง่ายดายในฝั่งไคลเอ็นต์

แก้ไข:ดังนั้นผู้โพสต์ดั้งเดิมจึงเพิ่ม URL ใหม่บางส่วนและยังคงชี้ไปที่ปัญหาฝั่งเซิร์ฟเวอร์ แต่ฉันแค่ต้องการโพสต์รายละเอียดสำหรับบันทึก

แนวคิด CDN ของ EdgeCast และ Highwinds

ดังนั้นผู้โพสต์ดั้งเดิมจึงเพิ่มรายละเอียดเพิ่มเติมดังนั้นนี่คือรายละเอียดเพิ่มเติมตามโพสต์บล็อกที่ใช้เป็นตัวอย่าง:

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

และ URL รูปภาพเหล่านี้มีไว้เพื่อเป็นตัวอย่างของ URL ในโพสต์นั้น:

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

และ URL รูปภาพทั้งสองนั้นก็ล้มเหลวอย่างแน่นอน แต่จากด้านข้างของฉัน - ดูที่รหัสดั้งเดิมของโพสต์บล็อกจาก Brooklyn, New York, USA - ฉันไม่เห็น EdgeCast ( gs1.wac.edgecastcdn.net) URL เหล่านั้น ค่อนข้างเป็น URL ที่ฉันเห็น:

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

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

ดังนั้นความคิดแรกของฉันคือทำไมโปสเตอร์ต้นฉบับจึงเห็น EdgeCast ( gs1.wac.edgecastcdn.net) แต่ถ้าฉันทำ traceroute ให้41.media.tumblr.comฉันเห็นว่าเป็นเซิร์ฟเวอร์ที่จัดการโดย Highwinds (!?!?) ในทางตรงกันข้าม URL เริ่มต้นที่ผู้ใช้ดั้งเดิมส่งผ่านนั้นกำลังใช้36.media.tumblr.comชื่อโฮสต์และคุณสามารถดูได้ว่าจัดการโดยเซิร์ฟเวอร์ Amazon CloudFront CDN

ซึ่งทั้งหมดนี้คือสิ่งที่ฉันพูดไว้ก่อนหน้านี้ทั้งหมดนี้น่าจะเป็นปัญหาด้านเซิร์ฟเวอร์กับ Tumblr และการจัดการ CDN ของพวกเขา แต่จากด้านข้างของฉัน - ใน Brooklyn, New York, USA - ฉันเห็นชัดเจนว่าเนื้อหาถูกส่งตามที่คาดหวังจากเซิร์ฟเวอร์ Highwinds CDN รวมถึง Amazon Amazon CloudFront CDN เซิร์ฟเวอร์ ที่ EdgeCast URLS เหล่านี้มาจากไหนหรือทำไมพวกเขาถึงล้มเหลวนั้นอยู่นอกเหนือการควบคุมของใคร ๆ ในฝั่งไคลเอ็นต์ นี่จะเป็นสิ่งที่ต้องติดต่อเจ้าหน้าที่ด้านเทคนิคของ Tumblr เพราะไม่มีทางที่ผู้ใช้คอมพิวเตอร์เดสก์ท็อปสามารถแก้ไขปัญหานี้ได้

ไอเดียการปลิงภาพ

อาจไม่เกี่ยวข้องอีกต่อไป แต่เพื่อการอ้างอิง

คุณระบุสิ่งนี้ให้เบาะแสฉัน:

ใช้wgetงานลิงค์โดยตรงของภาพได้

เว็บไซต์หลายแห่งมีกฎระเบียบอยู่ - โดยปกติจะตั้งค่าผ่าน Apache - ซึ่งป้องกันการรั่วไหลของภาพ รายละเอียดเพิ่มเติมเกี่ยวกับวิธีการทำงานของกฎเหล่านี้มีให้ที่นี่และสรุปดังนี้

การใช้. htaccess คุณสามารถไม่อนุญาตการเชื่อมโยงร้อนๆบนเซิร์ฟเวอร์ของคุณดังนั้นผู้ที่พยายามเชื่อมโยงไปยังไฟล์รูปภาพหรือไฟล์ CSS บนเว็บไซต์ของคุณอาจถูกบล็อก (คำขอที่ล้มเหลวเช่นภาพที่ไม่สมบูรณ์) หรือแสดงเนื้อหาอื่น ( เช่น: ภาพของผู้ชายที่โกรธ)

จากคำอธิบายของคุณและความจริงที่ว่าคุณสามารถเข้าถึงภาพผ่าน - wgetทำให้ฉันเชื่อว่าภาพที่คุณมีปัญหาไม่ได้ถูกโฮสต์ใน Tumblr โดยผู้ใช้ แต่เป็นภาพที่วางไว้ในบล็อก Tumblr แต่โฮสต์ไว้ที่อื่น เว็บไซต์.

เมื่อวางกระบวนการ leeching อิมเมจมาตรฐานไว้แล้วการดูอิมเมจที่ฝังในไซต์หนึ่งที่โฮสต์บนไซต์อื่นซึ่งบล็อก leeching จะส่งผลให้ลิงค์อิมเมจแตกหรืออาจเป็น“ Stop Leeching!” กำลังส่งคืนรูปภาพ นี่เป็นเพราะกฎการป้องกันการรั่วขั้นพื้นฐาน - เช่นในหน้าตัวอย่าง - ผู้อ้างอิงรูปภาพ crosscheck เพื่อให้แน่ใจว่าหน้าขอภาพตรงกับโดเมนที่โฮสต์ภาพ

ดังนั้นเมื่อคุณเข้าถึงภาพผ่านทางwgetคุณกำลังเข้าถึงภาพโดยตรง ดังนั้นกฎการ leeching ของรูปภาพจะไม่เตะดังนั้นคุณสามารถรับภาพผ่านwgetได้ แต่จะไม่ถูกฝังในอีกหน้า

ฉันกำลังมีปัญหาอย่างนี้ นี้มีความปลอดภัยสำหรับการทำงานดีมันเป็น comic- โง่ตัวอย่างของบล็อกได้รับผลกระทบ

หากพบว่ามีปัญหาเกิดขึ้นใน Chrome สำหรับฉันเท่านั้น หลังจากนั้นไม่นานฉันก็พบว่าสาเหตุของปัญหาคือส่วนขยาย“ HTTPS ทุกที่ ” เมื่อฉันติดตั้งใน Firefox ฉันมีปัญหาเดียวกันนั่นด้วย และถ้าฉันปิดการใช้งานกฎ HTTPS“ Tumblr (บางส่วน)” (ซึ่งฉันเดาว่าหมายถึง*.tumblr.com) มันก็ใช้ได้ดีอีกครั้ง

ดังนั้นปัญหาน่าจะเป็นอย่างน้อยในบางครั้งเมื่อมีการใช้ HTTPS เพื่อเข้าถึงรูปภาพคุณจะถูกเปลี่ยนเส้นทางไปยัง EdgeCast URL ที่ไม่ถูกต้อง ตัวอย่างเช่น URL รูปภาพนี้ทำงานได้ดี:

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

แต่ถ้าคุณเปลี่ยนโปรโตคอลจากhttpเป็นhttpsคุณจะได้รับการเปลี่ยนเส้นทางไปยัง URL นี้ซึ่งไม่ทำงาน:

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

ฉันไม่แน่ใจว่าสิ่งนี้นับเป็นข้อผิดพลาดจากด้าน Tumblr หรือไม่ ฉันเดาว่าถ้าลูกค้าไม่ควรเข้าถึงเซิร์ฟเวอร์สื่อด้วย HTTPS คุณไม่สามารถตำหนิพวกเขาได้

แก้ไข:และจริง ๆ แล้วปัญหาดูเหมือนว่าจะได้รับการจัดการตามที่รายงานไว้ในกระทู้ GitHubนี้

ฉันสังเกตเห็นพฤติกรรมนี้มากขึ้นในขณะที่ผู้ให้บริการมือถือ T-Mobile ฉันคิดว่านี่เป็นรูปแบบของปริมาณข้อมูลที่ปรับตามขนาดภาพหรือผู้ให้บริการบางรายสร้าง "ความยากลำบาก" ในการกล่าวถึงรายการ

ในการทดสอบก่อนหน้านี้ - เมื่อหนึ่งปีที่แล้ว - ฉันได้แชร์โพสต์ที่เสียหายไปยังเพื่อนที่มี Verizon และภาพโหลดได้ดี

ในขณะที่ฉันไม่สามารถทดสอบภาพนี้ฉันกำลังจะจัดเตรียม - เนื่องจากเพื่อนของฉันไม่พร้อมใช้งาน - ภาพนี้ไม่โหลดสำหรับฉัน ฉันใช้งาน Android หุ้น (5.0.1) บน Nexus 5 โดยใช้ Chrome เป็นเบราว์เซอร์

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

เมื่อฉันพยายามที่จะโหลดภาพโดยตรงฉันได้รับข้อผิดพลาดการหมดเวลาเกตเวย์ 504

แก้ไข:นี่คือ @ Jakeake จะโพสต์ภาพที่แท้จริงสำหรับการอ้างอิง

การทดสอบและรายละเอียดเพิ่มเติม: ฉันอยู่ใน Baltimore MD กำลังใช้งานข้อมูล LTE และภาพต่อไปนี้ทำงาน: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

การทดสอบเพิ่มเติมแสดงว่า PNG ดูเหมือนจะไม่เป็นปัญหา ภาพอื่น ๆ ที่ฉันได้ชมส่วนใหญ่นั้นเป็นการผสมผสานระหว่าง png และ jpg แต่ทั้งหมดนั้นอยู่ในเซิร์ฟเวอร์ที่ไม่ใช่ "41"

หมายเหตุสุดท้าย: ฉันกลับถึงบ้านกระโดดบน wifi ของฉัน - ออกอากาศ - ด้วยโทรศัพท์ของฉัน - อุปกรณ์ที่ฉันได้รับการทดสอบ - และรูปถ่ายทั้งหมดที่ฉันมองไม่เห็นเนื่องจาก 504 ฉันสามารถดูได้ในตอนนี้

แก้ไข:ใหม่ไปยัง superuser โพสต์ที่ถูกตัดและแก้ไขดังนั้นมันจึงเป็นจริงมากขึ้นและการสนทนาน้อยลง

อัปเดต:ดูเหมือนว่าปัญหาจะเชื่อมโยงกับ LTE เต็มไปด้วย Tumblr พบภาพบางรูปที่ไม่โหลดโหลดโทรศัพท์ของฉันลงไปที่ 3g หน้าโหลดซ้ำภาพทั้งหมดแสดง เปลี่ยนกลับโทรศัพท์เป็น LTE ล้างแคชและรูปภาพที่ก่อนหน้านี้ไม่ได้โหลดภายใต้ LTE ขณะนี้โหลด
(ฉันกำลังทดสอบอีกครั้งและตอนนี้ฉันไม่สามารถทำซ้ำได้ดังนั้นพฤติกรรมข้างต้นอาจเป็นความบังเอิญ)