ОБНОВЛЕНИЕ: Кажется, что основная проблема с изображениями, не загружающимися, проистекает из способа , которым плагин / расширение HTTPS Everywhere EFF обрабатывал некоторые URL Tumblr. Разработчик был уведомлен, и исправление, похоже, на месте . Этот ответ в основном разбивает детективную работу, проделанную, чтобы раскрыть проблему, описанную в первоначальном вопросе, и может оказаться полезной для дальнейшей отладки / диагностики, если подобная проблема появится в будущем.
РЕДАКТИРОВАТЬ: более широкий контент о пиявке изображения кажется недействительным. Так что добавим новую идею вверху и оставим информацию об изображении внизу на тот случай, если она кому-нибудь пригодится.
Amazon CloudFront CDN Идеи
Хорошо, используя предоставленные вами URL-адреса, а также некоторые из моего реального опыта работы с настройками Amazon CloudFront CDN, мне кажется, я кое-что обнаружил. Похоже, конфигурация 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 является то, что при первом доступе будет передано сообщение «Мисс от облачного фронта», а затем, если вы сразу же сделаете другое, curl -Iдолжно быть Hit from cloudfront.
Но это не то, что я видел только сейчас. Вот разбивка Dateи X-Cacheсостояние группы обращений, которые я сделал:
Date: Thu, 05 Mar 2015 02:19:37 GMT знак равно X-Cache: Miss from cloudfrontDate: Thu, 05 Mar 2015 02:19:39 GMT знак равно X-Cache: Miss from cloudfrontDate: Thu, 05 Mar 2015 02:19:44 GMT знак равно X-Cache: Miss from cloudfrontDate: Thu, 05 Mar 2015 02:19:50 GMT знак равно X-Cache: Miss from cloudfrontDate: Thu, 05 Mar 2015 02:19:50 GMT знак равно X-Cache: Hit from cloudfrontDate: Thu, 05 Mar 2015 02:19:50 GMT знак равно X-Cache: Hit from cloudfrontDate: Thu, 05 Mar 2015 02:19:50 GMT знак равно X-Cache: Hit from cloudfront
Причина, по которой существует несколько элементов с одинаковыми точными данными, которые находятся Hit from cloudfrontближе к концу, заключается в том, что именно это происходит в CDN: если конечная точка CDN имеет файл, то она Dateсоотносится с фактической датой создания / изменения файла, который конечная точка имеет.
Вы замечаете, что первые четыре доступа разделены секундами, с разными датами / временем, и все они Miss from cloudfront, верно? Это означает, что конечная точка CDN просто повторяет, что была попытка получить доступ к этому файлу в то время, и все попытки были пропущены.
Итак, моя оценка этого заключается в том, что системы Tumblr не поспевают за CDN Amazon CloudFront, или CDN Amazon CloudFront не поспевают за Tumblr. Но в некотором смысле, все не так на их стороне сервера. А поскольку это CDN, кто-то, имеющий доступ к файлам в одном месте, может не заметить проблему, в то время как кто-то в другом месте будет иметь проблемы с просмотром изображения.
Все это говорит о том, что я не думаю, что это можно легко прояснить на стороне клиента.
РЕДАКТИРОВАТЬ: Таким образом, оригинальный постер добавил несколько новых URL, и это все еще указывает на проблему на стороне сервера, но я просто хотел опубликовать детали для записи.
EdgeCast & Highwinds CDN Идеи
Итак, оригинальный постер добавил больше подробностей, так что вот больше деталей, основанных на посте в блоге, который используется в качестве примера:
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 изображения действительно терпят неудачу. Но со своей стороны - глядя на оригинальный исходный код сообщения в блоге из Бруклина, Нью-Йорк, США - я не вижу этих gs1.wac.edgecastcdn.netURL-адресов EdgeCast ( ). Скорее, это те 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). Но затем, если я сделаю трассировку маршрута, 41.media.tumblr.comя увижу, что это сервер, управляемый Highwinds (!?!?). В отличие от первоначальных URL-адресов, передаваемых исходным пользователем, используется 36.media.tumblr.comимя хоста, и вы можете видеть, что они управляются серверами Amazon CloudFront CDN.
Это все, что нужно сказать - о чем я говорил ранее, - кажется, что все это связано с Tumblr и управлением CDN на стороне сервера. Но со своей стороны - в Бруклине, штат Нью-Йорк, США - я отчетливо вижу, как контент доставляется, как и ожидалось, с серверов Highwinds CDN, а также с серверов Amazon CloudFront CDN. Откуда берутся эти URL-адреса EdgeCast или как и почему они перестают работать, никто не контролирует на стороне клиента. Об этом, безусловно, стоит обратиться к техническому персоналу Tumblr, потому что конечный пользователь настольного компьютера не может решить эту проблему.
Image Leeching Идеи
Может быть больше не актуально, но здесь для справки.
Вы заявляете об этом, дайте мне подсказку:
Использование wgetпрямых ссылок на изображения работает.
На многих сайтах действуют правила, обычно устанавливаемые через Apache, которые предотвращают распространение изображений. Более подробная информация о том, как работают эти правила, приведена здесь и суммирована следующим образом:
Используя .htaccess, вы можете запретить «горячие» ссылки на вашем сервере, поэтому те, кто пытается, например, создать ссылку на изображение или файл CSS на вашем сайте, либо блокируются (ошибочный запрос, например, испорченное изображение), либо обслуживают другой контент ( т.е. изображение злого человека).
Исходя из вашего описания - и того факта, что вы можете получить доступ к изображениям через wget-, я могу поверить, что изображения, с которыми у вас возникают проблемы, размещаются не на Tumblr пользователями, а скорее изображениями, которые размещаются в блоге Tumblr, но фактически размещаются в другом сайт.
Когда применяются стандартные процедуры передачи изображений, просмотр встроенного изображения на одном сайте, который размещен на другом сайте, который блокирует передачу, может привести к повреждению ссылки на изображение или, возможно, к прекращению распространения! изображение возвращается. Это связано с тем, что базовые правила защиты от пиявки, например, на странице примера, перепроверяют источники ссылок на изображения, чтобы убедиться, что страница, запрашивающая изображение, соответствует домену, в котором размещено изображение.
Поэтому, когда вы получаете доступ к изображению через него, wgetвы обращаетесь к изображению напрямую. Таким образом, правила передачи изображений не будут задействованы. Таким образом, вы можете получить изображение через, wgetно не тогда, когда оно встроено в другую страницу.
