Чому зображення з деяких сторінок 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-скрізь, схоже, іноді виправляється проблема.

_{Примітка:}

• _{У прикладі для №6 прямі посилання вказують на одне зображення. Однак, як правило, той, який використовується у публікації зображень (порівняно зі сторінкою, що збільшується), використовує меншу версію зображення, щоб відповідати темі сторінки. У прикладі використовується тема, створена для великих екранів, тому не потрібна менша версія.}

ОНОВЛЕННЯ: Здається, основна проблема із завантаженням зображень пов'язана з тим, як плагін / розширення HTTPS Everywhere для EFF обробляв деякі Tumblr URL-адреси. Про розробника надійшло сповіщення, і, здається, виправлено місце . Ця відповідь в основному розбиває детективну роботу, розроблену для розкриття проблеми, визначеної первинним запитанням, і може виявитися корисною для подальшої налагодження / діагностики, якщо подібне питання з’явиться в майбутньому.

РЕДАКТУВАННЯ: Більший вміст про вилуговування зображення здається недійсним. Таким чином, ви додасте нову ідею вгорі і залиште інформацію про випилювання зображення внизу, на випадок, якщо комусь це стане в нагоді.

Amazon CloudFront Ідеї CDN

Гаразд, використовуючи надані вами URL-адреси, а також деякий досвід мого реального досвіду щодо налаштувань CDN Amazon CloudFront - я думаю, що я щось виявив. Схоже, конфігурація CDN від Amazon CloudFront CDC 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 не йдуть в ногу з Amazon CloudFront CDN або Amazon CloudFront CDN не йде в ногу з Tumblr. Але якимось чином на їхньому сервері все не так. Оскільки це CDN, хтось, що отримує доступ до файлів в одному місці, може не помітити проблеми, тоді як у когось іншого місця виникнення проблем із переглядом зображення.

Це все, що потрібно сказати, я не думаю, що це можна легко зрозуміти на стороні клієнта.

EDIT: Отже, оригінальний плакат додав нові 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. Але з мого боку - в Брукліні, Нью-Йорк, США - я чітко бачу, як контент доставляється, як очікувалося, від CDN-серверів Highwinds, а також CDN-серверів Amazon CloudFront. Звідки ці URL-адреси EdgeCast надходять або як / чому вони не стають, не вдається контролювати когось із боку клієнта. З цим, безумовно, можна звернутися до технічного персоналу компанії Tumblr, тому що кінцевий користувач не може вирішити це.

Зображення Ідеї вилуговування

Можливо, це вже не актуально, але тут для довідки.

Ви заявляючи це, дайте мені підказку:

Використання 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, ви не можете реально звинувачувати їх у цьому.

EDIT: І насправді проблему, як видається, вирішили, як повідомлялося в цій темі GitHub .

Я більше помічав таку поведінку, перебуваючи на своєму мобільному операторі T-Mobile. Я думаю, що це якась форма руху трафіку на основі розміру зображення або якась "метрика складності", побудована носієм у відновленні зазначеного елемента.

У попередньому тестуванні - понад рік тому - я потім поділився непрацездатною публікацією другові, який має Verizon, і зображення прекрасно завантажується.

Поки я не можу перевірити це зображення, яке я збираюся надати - оскільки мій друг недоступний - це зображення не завантажується для мене. Я працюю на Android (5.0.1) на Nexus 5, використовуючи Chrome як браузер.

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

Коли я намагаюся завантажити зображення безпосередньо, я отримую помилку тайм-аута 504 шлюзу.

EDIT: Це @JakeGould публікує фактичне зображення для довідки.

Подальше тестування та детальні відомості: я перебуваю в Baltimore MD, працює з LTE-даними та працює наступне зображення: http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

Подальше тестування показує, що PNG, здається, не є проблемою. Більшість інших зображень, на які я потрапив, працювали - це суміш png та jpg, але всі вони були на серверах, що не "41".

Заключне зауваження: я повернувся додому, перестрибнув на свій wifi -Comcast- зі своїм телефоном - пристрій, який я тестував, - і всі фотографії, яких я не міг побачити через 504, які я зараз бачу.

РЕДАКТУВАННЯ: Новий для суперпопулярних, підстрижених та відредагованих публікацій, щоб було більше фактичних та менше дискусій.

ОНОВЛЕННЯ: Здається, випуск пов'язаний з LTE. Завантажили tumblr, знайшли зображення, які не завантажувались, змусили мій телефон до 3 г, перезавантажили сторінку, показали всі зображення. Повернений телефон назад до LTE, очищений кеш і зображення, які раніше не завантажувались під LTE, завантажуються.
(Я знову тестую, і тепер я не можу відтворити. Тож, можливо, вищезгадана поведінка була хитрою.)