Tại sao hình ảnh từ một số trang Tumblr không tải, nhưng sử dụng wget trên chúng hoạt động?

Giúp một người bạn kết nối Internet của họ vì một số trang sẽ không tải được, tôi nhận thấy rằng vấn đề là hình ảnh của các bài đăng hình ảnh của một số blog không tải trên trình duyệt. Tôi thấy nó kỳ lạ vì những lý do sau:

1. Chỉ những hình ảnh là một phần của bài đăng sẽ không tải. Hình đại diện người dùng, biểu ngữ, tiêu đề, chủ đề khác nhau và / hoặc hình ảnh liên quan đến trang vẫn xuất hiện.
2. Xảy ra với bất kỳ trình duyệt nào trên máy tính (Đã thử nghiệm trên Firefox và Chrome / ium cả có và không có trình chặn quảng cáo / tập lệnh).
3. Sử dụng wgettrên các liên kết trực tiếp của hình ảnh hoạt động.
4. Điều này không áp dụng cho tất cả các trang Tumblr. Hầu hết tải đúng cách, nhưng khi tạo danh sách các trang có bài đăng không tải hình ảnh cho thấy chúng hầu hết đến từ cùng một nhóm người dùng.
5. Vấn đề dường như là cụ thể theo blog theo nghĩa là nếu một bài đăng hình ảnh của một blog nào đó không tải trong trình duyệt, các blog khác (không bị ảnh hưởng hay không) đã đăng lại cùng một bài đăng cũng sẽ không tải hình ảnh trong trình duyệt. Ngược lại, nếu một blog bị ảnh hưởng được reblog từ một blog không bị ảnh hưởng, hình ảnh sẽ tải tốt.
6. Các hình ảnh là từ các bài đăng Tumblr do người dùng tạo, nơi người dùng tải lên một hình ảnh để đăng và được lưu trữ bởi Tumblr. Ví dụ (ví dụ này không phải là một trong những blog bị ảnh hưởng), trong bài đăng hình ảnh này (được chọn ngẫu nhiên), đây sẽ là liên kết trực tiếp đến hình ảnh trong bài đăng. Bài đăng hình ảnh tự động làm cho hình ảnh trở thành một liên kết đến một trang khác trong Tumblr bằng cách sử dụng phiên bản lớn hơn (thường) của hình ảnh được sử dụng trong bài đăng gần với kích thước của những gì người dùng đã tải lên cho bài đăng.

Điều gì có thể có thể là lý do cho điều này xảy ra? Phần thực sự mang lại cho tôi là thực tế wgethoạt động, vì vậy tôi nghĩ rằng tôi có thể cho rằng đó không phải là vấn đề với kết nối mạng.

Cập nhật:

Dưới đây là một ví dụ về một bài đăng được đăng lại mà không tải được trên các trình duyệt. Các blog chính có bài viết hình ảnh khác mà nạp đúng cách. Đây là liên kết trực tiếp đến hình ảnh trong bài đăng và đây là liên kết cho phiên bản lớn hơn (cả hai đều không tải ở đây). wgethoạt động cho cả hai, nhưng khi đi đến bất kỳ liên kết trực tiếp nào với Firefox, lỗi này xuất hiện:

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>

RequestIDvà HostIdthay đổi mọi lúc. Bạn tôi và tôi đang ở Philippines.

Cập nhật [2014/03/08]

Sau khi kiểm tra thêm và trả lời email của bộ phận hỗ trợ Tumblr, wgetđã ngừng hoạt động (nhận 403 lỗi trên các liên kết trực tiếp) trong một số trường hợp.

Cập nhật [2014/03/09]

Tắt các quy tắc Tumblr cho HTTPS - Mọi nơi dường như đôi khi khắc phục sự cố.

_{Ghi chú:}

• _{Trong ví dụ cho # 6, liên kết trực tiếp cả hai điểm đến cùng một hình ảnh. Tuy nhiên, thông thường, cái được sử dụng trong bài đăng hình ảnh (so với trang hình ảnh có thể phóng to) sử dụng một phiên bản nhỏ hơn của hình ảnh để phù hợp với chủ đề của trang. Ví dụ sử dụng một chủ đề được tạo cho màn hình lớn hơn nên không cần phiên bản nhỏ hơn.}

CẬP NHẬT: Có vẻ như vấn đề cốt lõi với hình ảnh không được tải xuất phát từ cách plugin / tiện ích mở rộng HTTPS Everywhere của EFF xử lý một số URL Tumblr. Các nhà phát triển đã được thông báo và có một bản sửa lỗi được đưa ra . Câu trả lời này về cơ bản phá vỡ công việc thám tử được thực hiện để khám phá vấn đề như được nêu trong câu hỏi ban đầu và có thể chứng minh hữu ích cho việc gỡ lỗi / chẩn đoán thêm nếu một vấn đề tương tự xuất hiện trong tương lai.

EDIT: Nội dung lớn hơn về leeching hình ảnh có vẻ không hợp lệ. Vì vậy, sẽ thêm một ý tưởng mới ở phía trên và để lại thông tin leeching hình ảnh ở phía dưới chỉ trong trường hợp nó hữu ích cho ai đó.

Ý tưởng CDN của Amazon CloudFront

Được rồi, bằng cách sử dụng các URL mà bạn đã cung cấp, cũng như một số trải nghiệm trong thế giới thực của tôi với các thiết lập CDN của Amazon CloudFront, tôi nghĩ rằng tôi đã phát hiện ra điều gì đó. Có vẻ như cấu hình CDN Amazon CloudFront của Tumblr bị nghẹt thở vì một số lý do. Đây là lý do tại sao tôi nghĩ rằng đó là trường hợp.

Hãy lấy URL ví dụ này:

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

Bây giờ hãy chạy curl -Iđể lấy thông tin tiêu đề trên tệp đó:

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

Đầu ra cho điều đó sẽ là một cái gì đó như thế này:

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

Bây giờ, điều cần chú ý ở đây là Date(ngày và giờ của tệp trên điểm cuối CloudFront) và X-Cache(trạng thái phân phối nội dung của Amazon). Hành vi điển hình trên Amazon CloudFront là quyền truy cập đầu tiên sẽ truyền tải một Miss Miss từ đám mây trên nền tảng đám mây và sau đó nếu bạn thực hiện một thao tác khác curl -Ingay sau đó thì nên có một Hit from cloudfront.

Nhưng đó không phải là những gì tôi thấy bây giờ. Đây là một sự cố về Datevà X-Cachetrạng thái của một loạt các truy cập tôi đã thực hiện:

• 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

Lý do tại sao có nhiều mục có cùng dữ liệu chính xác Hit from cloudfrontở gần cuối là vì đó là những gì xảy ra trên CDN: Nếu điểm cuối của CDN có tệp, thì Datetương quan với ngày tạo / sửa đổi thực tế của tệp đó điểm cuối có.

Bạn nhận thấy bốn lần truy cập đầu tiên cách nhau vài giây, với ngày / giờ khác nhau và tất cả chúng đều Miss from cloudfrontđúng, phải không? Điều đó có nghĩa là điểm cuối CDN chỉ lặp lại rằng có một nỗ lực truy cập tệp đó vào thời điểm đó và tất cả các lần thử đều bị bỏ lỡ.

Vì vậy, đánh giá ghế bành của tôi về điều này là các hệ thống của Tumblr không theo kịp CDN của Amazon CloudFront hoặc CDN của Amazon CloudFront không theo kịp Tumblr. Nhưng theo một cách nào đó, mọi thứ đều không ổn ở phía máy chủ của họ. Và vì đây là CDN, nên ai đó truy cập vào các tệp ở một vị trí có thể không nhận thấy sự cố trong khi một người khác ở vị trí khác sẽ gặp sự cố khi xem hình ảnh.

Đó là tất cả để nói, tôi không nghĩ rằng điều này có thể dễ dàng được làm sáng tỏ về phía khách hàng.

EDIT: Vì vậy, người đăng ban đầu đã thêm một số URL mới và điều này vẫn chỉ ra vấn đề phía máy chủ, nhưng tôi chỉ muốn đăng chi tiết cho bản ghi.

Ý tưởng CDN của EdgeCast & Highwinds

Vì vậy, áp phích gốc đã thêm chi tiết cụ thể hơn, vì vậy đây là chi tiết hơn dựa trên bài đăng trên blog đang được sử dụng làm ví dụ:

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

Và các URL hình ảnh này được cung cấp dưới dạng ví dụ về các URL trong bài đăng đó:

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

Và hai URL hình ảnh đó thực sự thất bại. Nhưng từ phía tôi, tôi nhìn vào mã soure gốc của bài đăng trên blog từ Brooklyn, New York, Hoa Kỳ. Tôi không thấy các URL EdgeCast ( gs1.wac.edgecastcdn.net) đó. Thay vào đó, đây là các URL tôi đang thấy:

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

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

Vì vậy, suy nghĩ đầu tiên của tôi là tại sao người đăng ban đầu nhìn thấy những EdgeCast ( gs1.wac.edgecastcdn.net) đó. Nhưng sau đó nếu tôi thực hiện theo dõi đến thì 41.media.tumblr.comtôi thấy đó là một máy chủ được quản lý bởi Highwinds (!?!?). Ngược lại, các URL ban đầu được chuyển bởi người dùng ban đầu đang sử dụng 36.media.tumblr.comtên máy chủ và bạn có thể thấy chúng được quản lý bởi các máy chủ CDN của Amazon CloudFront.

Đó là tất cả những gì để nói, mà tôi đã nói trước đó, tất cả những điều này dường như là vấn đề của máy chủ với Tumblr và quản lý CDN của họ. Nhưng từ phía tôi, ở Brooklyn, New York, Hoa Kỳ, tôi thấy rõ nội dung được phân phối như mong đợi từ các máy chủ CDN của Highwinds cũng như các máy chủ CDN của Amazon CloudFront. Các URL EdgeCast này đến từ đâu hoặc tại sao / tại sao chúng không thành công nằm ngoài tầm kiểm soát của bất kỳ ai ở phía máy khách. Đây chắc chắn sẽ là điều cần liên hệ với nhân viên công nghệ Tumblr vì không có cách nào người dùng cuối máy tính để bàn có thể giải quyết vấn đề này.

Ý tưởng hình ảnh Leeching

Có thể không liên quan nữa, nhưng ở đây để tham khảo.

Bạn nói điều này cho tôi một manh mối:

Sử dụng wgettrên các liên kết trực tiếp của hình ảnh hoạt động.

Nhiều trang web có các quy tắc tại vị trí thường được thiết lập thông qua Apache mà ngăn chặn việc lấy hình ảnh. Chi tiết hơn về cách thức các quy tắc này được cung cấp ở đây và được tóm tắt như sau:

Ví dụ, sử dụng .htaccess, bạn có thể không cho phép liên kết nóng trên máy chủ của mình, do đó, những người cố liên kết đến một hình ảnh hoặc tệp CSS trên trang web của bạn, chẳng hạn, bị chặn (yêu cầu không thành công, chẳng hạn như hình ảnh bị hỏng) hoặc được cung cấp một nội dung khác ( tức là: một hình ảnh của một người đàn ông tức giận).

Dựa trên mô tả của bạn, và thực tế là bạn có thể truy cập các hình ảnh qua thông wgettin của tôi để tin rằng những hình ảnh bạn gặp sự cố không được lưu trữ trên Tumblr bởi người dùng, mà là những hình ảnh được đặt trên blog Tumblr nhưng thực sự được lưu trữ trên một trang khác Địa điểm.

Khi các quy trình xử lý hình ảnh tiêu chuẩn được đưa ra, việc xem một hình ảnh được nhúng trên một trang web được lưu trữ trên một trang web khác, đó là việc chặn leeching sẽ dẫn đến một liên kết hình ảnh bị hỏng hoặc có thể là một Stop Stop Leeching! hình ảnh được trả lại. Điều này là do các quy tắc chống đỉa cơ bản, chẳng hạn như các quy tắc trong trang ví dụ đó, giới thiệu hình ảnh kiểm tra chéo để đảm bảo trang yêu cầu hình ảnh khớp với tên miền lưu trữ hình ảnh.

Vì vậy, khi bạn đang truy cập hình ảnh thông qua wgetbạn đang truy cập hình ảnh trực tiếp. Vì vậy, các quy tắc leeching hình ảnh sẽ không khởi động. Vì vậy, bạn có thể có được hình ảnh thông qua wgetnhưng không phải khi nó được nhúng vào một trang khác.

Tôi hiện đang có vấn đề này rất nhiều. Đây là một cách an toàn cho công việc, đó là một ví dụ truyện tranh ngớ ngẩn của một blog bị ảnh hưởng .

Tuy nhiên, nếu tìm thấy sự cố chỉ xảy ra trong Chrome đối với tôi. Sau một thời gian, tôi nhận ra rằng nguyên nhân của vấn đề là do tiện ích mở rộng HTTPS ở mọi nơi . Khi tôi cài đặt nó trong Firefox, tôi cũng gặp vấn đề tương tự. Và thực tế, nếu tôi vô hiệu hóa quy tắc HTTPS, thì Tum Tumr (một phần), (mà tôi đoán là có nghĩa *.tumblr.com), nó hoạt động tốt trở lại.

Vì vậy, vấn đề dường như là, ít nhất , đôi khi , khi HTTPS được sử dụng để truy cập một hình ảnh, bạn được chuyển hướng đến một URL EdgeCast không hợp lệ. Ví dụ: URL hình ảnh này hoạt động tốt:

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

Nhưng nếu bạn thay đổi giao thức từ httpthành httpsbạn sẽ được chuyển hướng đến URL này không hoạt động:

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

Tôi không chắc chắn nếu điều này được tính là một lỗi từ phía Tumblr hay không. Tôi đoán rằng nếu khách hàng không được phép truy cập máy chủ phương tiện của họ bằng HTTPS, bạn không thể thực sự đổ lỗi cho họ vì điều đó.

EDIT: Và thực sự vấn đề dường như đã được xử lý như được báo cáo trong chủ đề GitHub này .

Tôi đã nhận thấy hành vi này nhiều hơn trong khi trên nhà mạng di động của tôi, T-Mobile. Tôi nghĩ rằng đây là một số loại hình lưu lượng truy cập dựa trên kích thước hình ảnh hoặc một số nhà cung cấp được xây dựng độ khó của hệ số khó khăn trong việc phản hồi lại mục đã nói.

Trong thử nghiệm trước đây, hơn một năm trước, tôi đã chia sẻ bài đăng bị hỏng cho một người bạn có Verizon và hình ảnh tải rất tốt.

Mặc dù tôi không thể kiểm tra hình ảnh này nhưng tôi sắp cung cấp cho bạn vì bạn tôi không có sẵn, nhưng hình ảnh này không tải cho tôi. Tôi đang chạy Android stock (5.0.1) trên Nexus 5 bằng Chrome làm trình duyệt.

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

Khi tôi cố tải hình ảnh trực tiếp, tôi gặp lỗi hết thời gian chờ cổng 504.

EDIT: Đây là @JakeGould đăng hình ảnh thực tế để tham khảo.

Thử nghiệm và chi tiết khác: Tôi đang ở Baltimore MD, chạy hết dữ liệu LTE và hình ảnh sau đã hoạt động: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1500.jpg

Thử nghiệm thêm cho thấy PNG dường như không phải là vấn đề. Hầu hết các hình ảnh khác mà tôi đạt được đều hoạt động là sự pha trộn giữa png và jpg, nhưng tất cả đều ở trên các máy chủ không "41".

Lưu ý cuối cùng: Tôi về nhà, bật wifi của tôi -Comcast- với điện thoại của tôi - thiết bị tôi đã thử nghiệm - và tất cả những bức ảnh tôi không thể nhìn thấy do 504 bây giờ tôi có thể nhìn thấy.

EDIT: Mới đối với superuser, bài viết được cắt xén và chỉnh sửa để nó thực tế hơn và ít thảo luận hơn.

CẬP NHẬT: Vấn đề dường như được gắn với LTE. Tải lên tumblr, tìm thấy một số hình ảnh sẽ không tải, buộc điện thoại của tôi xuống còn 3g, trang tải lại, tất cả hình ảnh hiển thị. Điện thoại được hoàn nguyên trở lại LTE, xóa bộ nhớ cache và hình ảnh trước đây không tải trong LTE hiện đang tải.
(Tôi đang thử nghiệm lại và bây giờ tôi không thể sao chép. Vì vậy, có thể hành vi trên là một sự cố.)