ОБНОВЛЕНИЕ: Кажется, что основная проблема с изображениями, не загружающимися, проистекает из способа , которым плагин / расширение 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 изображения действительно терпят неудачу. Но со своей стороны, глядя на оригинальный исходный код сообщения в блоге из Бруклина, Нью-Йорк, США, я не вижу этих URL-адресов EdgeCast (gs1.wac.edgecastcdn.net). Скорее, это те 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 но не тогда, когда оно встроено в другую страницу.
