Сторінка завантажується, текст відображається, а одне зображення лишається зламаною іконкою. Перша реакція — звинуватити тунель, бо саме тунель змінився. Перед тим з'ясуйте, який URL браузер насправді запитав для цього зображення, бо URL сторінки й URL зображення — два різні докази. Більшість повідомлень про відсутнє зображення зводяться до хоста, який так і не отримав робочого запиту, і ця відповідь коштує одного погляду на панель «Мережа».

Де шукати, визначають три умови

Перша умова — чи приходить зображення з того самого хоста, що й сторінка. Окремому хосту зображень потрібні власне розв'язання імен, власне з'єднання та власна ідентичність TLS, тож сторінка, яка завантажується, нічого про нього не каже.

Друга — чи заблокував браузер запит до його надсилання. Змішаний вміст, політика безпеки вмісту та правила реферера можуть зупинити зображення, не створивши звичайної відповіді сервера, тому в списку не з'являється жодного невдалого запиту.

Третя — чи доставка вдалася, а відображення ні, випадок, коли байти надходять, а зображення все одно не з'являється. Ці три умови мають трьох різних власників, і лише перша є питанням мережі.

What you seeWhere the fault sits
Request absent from the listMarkup, lazy loading or a policy that blocked it
Request failed or timed outResolution, route, TLS or the image host itself
Request returned 200, image blankResponse type, decoding or rendering

Знайдіть ресурс, який браузер справді вибрав

URL, який ви бачите у вихідному коді сторінки, часто не той, що був запитаний. Набори джерел, елементи picture і фони CSS дозволяють браузеру вибрати інший ресурс залежно від ширини області перегляду, щільності пікселів або підтримки формату. Ліниво завантажуване зображення може взагалі не запитуватися, доки сторінка не досягне певного стану.

Огляньте елемент і запит разом, і зберігайте ініціатора поруч із запитом, коли повідомляєте про проблему. Довідник з елемента зображення від MDN в одному місці охоплює вибір джерела, поведінку завантаження й керування реферером, чого достатньо, щоб визначити, який атрибут вибрав невдалий URL.

Запишіть ім'я хоста, статус, будь-який ланцюжок переспрямувань і тип вмісту відповіді. Відповідь 200, яка повертає сторінку входу, не є придатним зображенням, а переспрямування на HTML-сторінку помилки виглядає так само, як пошкоджений файл, доки ви не прочитаєте тип.

Читайте статус раніше за мережу

Тайм-аут, відхилений запит і помилка декодування потребують різних наступних кроків, і саме код стану їх розділяє. Тайм-аут указує на розв'язання імен, маршрут або хост, що не відповідає. Відхилений запит указує на політику або рівень авторизації. Помилка декодування вказує на байти або формат.

Якщо запит узагалі не з'являється, припиніть дивитися на мережу й подивіться на розмітку. Найчастіша причина — запис у наборі джерел, якому браузер віддав перевагу і якого вже немає на сервері, а за ним елемент, який скрипт так і не зробив видимим.

Саме це розрізнення запобігає більшій частині марної роботи в повідомленнях такого типу.

Коли браузер блокує, читати відповідь нічого

Змішаний вміст — класичний випадок: сторінка HTTPS, що запитує зображення звичайним HTTP, отримує запит заблокованим, а не невдалим, і консоль записує причину. Політика безпеки вмісту дає ту саму форму, а заблокована директива називається в повідомленні. Політика реферера, яка прибирає заголовок, також може змусити хост із захистом від хотлінків повернути заглушку замість зображення.

Прочитайте записану причину, перш ніж торкатися мережевого шляху, бо ці блокування не покращуються, коли маршрут змінюється. Додавання дозволів між джерелами теж не рішення: показ зображення з іншого хоста й читання його пікселів у canvas — різні операції, і лише друга потребує заголовків, які люди вставляють.

Для сайту, яким ви керуєте, виправте URL ресурсу, відповідь або політику в її власника й збережіть вимоги авторизації та реферера незмінними. Для сайту, який ви не контролюєте, надішліть сторінку й докази запиту до його каналу підтримки замість повторної публікації приватних або прострочених посилань на ресурси.

Порівнюйте шляхи, не змінюючи доказів

Якщо ви справді хочете перевірити шлях доступу, тримайте все інше незмінним: та сама сторінка, той самий обліковий запис, те саме вибране зображення, один дозволений шлях змінено. Порівнюйте записи запитів поряд, а не відображений результат, бо відображений результат каже, чи з'явилося зображення, а не чому.

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

Порядок роботи: визначте вибраний URL, прочитайте його статус і тип, перевірте, чи є записана причина блокування, потім порівнюйте по одній зміні шляху за раз.

Схожі статті