Почему изображения с некоторых страниц 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-Everywhere, кажется, иногда решает проблему.

_{Замечания:}

• _{В примере для # 6 прямые ссылки указывают на одно и то же изображение. Обычно, однако, тот, который используется в посте с изображением (по сравнению со страницей с масштабируемым изображением), использует уменьшенную версию изображения, чтобы соответствовать теме страницы. В примере используется тема, созданная для больших экранов, поэтому для нее не требуется уменьшенная версия.}

ОБНОВЛЕНИЕ: Кажется, что основная проблема с изображениями, не загружающимися, проистекает из способа , которым плагин / расширение 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 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 не поспевают за 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но не тогда, когда оно встроено в другую страницу.

У меня сейчас такая проблема. Это безопасный для работы - ну, это глупый комикс - пример затронутого блога .

Однако, если обнаружил, что проблема произошла только в Chrome для меня. Через некоторое время я понял, что причиной проблемы было расширение « HTTPS Everywhere ». Когда я установил его в Firefox, у меня тоже была такая же проблема. И вообще, если я отключу правило HTTPS «Tumblr (частичное)» (что, я думаю, означает *.tumblr.com), оно снова будет работать нормально.

Таким образом, проблема заключается в том, что, по крайней мере, иногда , когда HTTPS используется для доступа к изображению, вы перенаправлены на недопустимый URL-адрес EdgeCast. Например, 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 шлюза.

РЕДАКТИРОВАТЬ: Это @JakeGould опубликовать фактическое изображение для справки.

Дальнейшее тестирование и детали: я нахожусь в Балтиморе, штат Мэриленд, работаю с данными LTE, и сработало следующее изображение: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

Дальнейшее тестирование показывает, что PNG, похоже, не является проблемой. Большинство других изображений, которые я ударил, которые работали, были смесью png и jpg, но все они были на не «41» серверах.

Последнее замечание: я вернулся домой, подключился к своему Wi-Fi -Comcast- со своим телефоном - устройством, на котором я тестировал, - и все фотографии, которые я не мог видеть из-за 504, теперь я вижу.

РЕДАКТИРОВАТЬ: плохо знакомый с суперпользователем, урезанный и отредактированный пост, так что это было более фактическим и меньше обсуждения.

ОБНОВЛЕНИЕ: Проблема, кажется, связана с LTE. Загрузил Tumblr, нашел несколько изображений, которые не загружались, заставил мой телефон опуститься до 3g, перезагрузил страницу, все изображения показываются. Вернул телефон обратно в LTE, очистил кеш, и теперь загружаются изображения, которые ранее не загружались под LTE.
(Я снова тестирую, и теперь я не могу воспроизвести. Возможно, вышеупомянутое поведение было случайностью.)