обновление: кажется, основная проблема с изображениями не загружая вытекает из того, как EFF HTTPS Everywhere плагин / расширение обрабатываются некоторые URL-адреса Tumblr. Разработчики были уведомлены и исправить оказывается на месте. Этот ответ в основном разбивает детективную работу, проделанную для выявления проблемы, как указано в первоначальном вопросе, и может оказаться полезным для дальнейшей отладки/диагностики, если подобная проблема появляется в будущий.
изменить: большее содержание о leeching изображения кажется недействительным. Так будет добавить новую идею в верхней и оставить изображение leeching информацию в нижней части только в случае, если это полезно для кого-то.
идеи 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-первый доступ передаст "промах от 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 не поспевают за Amazon CloudFront CDN или Amazon CloudFront CDN не поспевает за 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-адреса изображений действительно терпят неудачу. Но с моей стороны, глядя на исходный код sure сообщения в блоге из Бруклина, Нью-Йорк, США, я не вижу этих 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 hostname и вы можете видеть, что они управляются серверами Amazon CloudFront CDN.
что все сказать-что я сказал раньше - все это, кажется, проблема на стороне сервера с Tumblr и их управлением CDN. Но с моей стороны-в Бруклине, Нью-Йорк, США-я четко вижу, что контент доставляется, как и ожидалось, с серверов HIGHWINDS CDN, а также серверов Amazon CloudFront CDN. Где эти EDGECAST URL-адреса приходят из или как / почему они затем терпят неудачу находится вне чьего-либо контроля на стороне клиента. Это определенно было бы чем-то, чтобы связаться с техническим персоналом Tumblr, потому что конечный пользователь рабочего стола не мог реши это.
Изображение Leeching Идеи
уже не актуально, но вот для справки.
вы заявляете это, дайте мне подсказку:
используя wget по прямым ссылкам изображений работает.
многие сайты имеют правила-обычно установленные через Apache-которые предотвращают leeching изображений. Подробнее о том, как работают эти правила здесь и кратко изложить следующим образом:
использование .htaccess, вы можете запретить горячие ссылки на вашем сервере, так что те
пытаясь ссылку на изображение или CSS-файл на вашем сайте, например,
заблокирован (неудачный запрос, например, поврежденный образ) или обслуживается
различное содержание (т. е. изображение злого человека).
на основе вашего описания-и тот факт, что вы можете получить доступ к изображениям через wget-приводит меня к мысли, что образы у вас возникли проблемы с не размещенные на Tumblr пользователями, а изображения, которые размещены в блоге Tumblr, но фактически размещены на другом сайте.
когда стандартные процедуры leeching изображения ставятся на место, просмотр встроенного изображения на одном сайте, который размещен на другом сайте-который блокирует leeching-приведет к сломанной ссылке изображения или, возможно, " остановить Leeching!"изображение возвращается. Это связано с тем, что основные правила защиты от leeching, такие как в этом примере страницы, проверяют ссылки на изображения, чтобы убедиться, что страница с просьбой изображение совпадает с доменом хостинг изображения.
так что при доступе к изображению через wget вы получаете доступ к изображения напрямую. Так правила скачиваю изображения не подействует. Таким образом, вы можете получить изображение через wget но не тогда, когда он встроен в другую страницу.
Komp
3400
