"ПОПЕРЕДЖЕННЯ: відображаються попередні заголовки" у відладчику Chrome

Я помітив дивне повідомлення про обережність, переглядаючи завантажені ресурси за допомогою хромового інспектора Google ( F12):

Показано попередження попередніх заголовків

Мережева панель виявила щось, можливо, відповідне : додайте обережність щодо тимчасових заголовків запитів , але я не зміг повністю зрозуміти це. Пов’язані запитання можна знайти в запитах блокування Chrome , а також не можна завантажити XMLHttpRequest. Вивантажені ресурси демонструють обережність: відображаються попередні заголовки .

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

Ресурс може бути заблокований розширенням (у моєму випадку AdBlock).

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

Я дізнався про розширення, яке блокувало мій ресурс, через інструмент net-internes в Chrome:

Для останніх версій хрому

• Введіть chrome://net-export/адресний рядок і натисніть клавішу Enter.
• Почніть запис. І збережіть файл запису до локального.
• Відкрийте сторінку, на якій з’являються проблеми.
• Поверніться до мережі
• Ви можете переглянути тут записаний файл журналу https://netlog-viewer.appspot.com/#import
• натисніть на події (###) та використовуйте текстове поле, щоб знайти подію, пов’язану з вашим ресурсом (використовуйте частини URL-адреси).
• Нарешті, натисніть на подію і подивіться, чи відображена інформація про вас щось говорить.

Для старих версій хрому

• Введіть chrome://net-internalsадресний рядок і натисніть клавішу Enter.
• Відкрийте сторінку, на якій з’являються проблеми.
• Поверніться до net-internes, натисніть на події (###) та використовуйте текстове поле, щоб знайти подію, пов’язану з вашим ресурсом (використовуйте частини URL-адреси).
• Нарешті, натисніть на подію і подивіться, чи відображена інформація про вас щось говорить.

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

Для chrome v72 + це вирішило для мене лише це:

перейдіть chrome://flags/і вимкніть ці 3 прапори

• Вимкнути ізоляцію сайту
• Увімкнути мережевий сервіс
• Запускається мережеве обслуговування під час роботи

або ви можете зробити це з командного рядка:

chrome --disable-site-isolation-trials --disable-features=NetworkService,NetworkServiceInProcess

чому це трапляється?

Схоже, Google реконструює їх движок Chromium в модульну структуру, де різні сервіси будуть розділені на окремі модулі та процеси. Цей процес вони називають сервіфікацією. Служба мережі - це перший крок, з'являються сервіс Ui, послуга посвідчення особи та послуга пристрою. Google надає офіційну інформацію на сайті проекту Chromium .

чи небезпечно це змінити?

Прикладом є налагодження мереж: коли ми маємо мережевий сервіс, ми можемо вибрати, чи не вичерпати його для покращення стабільності / безпеки, або в процесі роботи, якщо у нас обмежені ресурси . джерело

Я зіткнувся з цим питанням, і мені вдалося визначити конкретну причину, про яку не згадувалося вище ні у відповідях, ні в запитанні.

Я використовую повний стек js, кутовий передній і задній кінець вузла на SSL, а API знаходиться на іншому домені, який працює на порту 8081, тому я роблю запити CORS та withCredentials, коли я скидаю cookie сеансу з API

Отже, конкретно мій сценарій був: запит POST, withCredentials to port 8081 спричинив повідомлення "ПОПЕРЕДЖЕННЯ: тимчасові заголовки показані" в інспектора, а також, звичайно, заблокував цей запит разом.

Моїм рішенням було налаштувати apache для передачі проксі із звичайного порту SSL 443 до вузла порту SSL 8081 (вузол повинен бути на більш високому порту, оскільки він не може бути запущений як root у prod). Тож я думаю, що Chrome не любить SSL запити до нетрадиційних портів SSL, але, можливо, їх повідомлення про помилку може бути більш конкретним.

Це також може статися (лише для запитів перехресного походження) через нову функцію під назвою ізоляція сайту

На цій сторінці детально розглядаються проблеми та вирішення проблеми . Що означає перейти chrome://flags/#site-isolation-trial-opt-outв хром та змінити це налаштування на "Відмовитися" та перезавантажити хром.

Це відоме питання . Однак на цій сторінці сказано, що вона зафіксована у хромі 68, але у мене працює хром 68, і у мене все ще є проблема.

HTTP / 2 Натиснені ресурси виробляються Provisional headers are shownв інспектора за тією ж теорією, що і @wvega, розміщена у його відповіді вище .

наприклад: Оскільки сервер передав клієнтові ресурси (до того, як клієнт запитав їх ), браузер має кешовані ресурси, і тому клієнт ніколи не робить / не потребує запитів; Тому що ...

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

Моя ситуація пов'язана між походженнями .
Ситуація: браузер надсилає OPTIONSзапит, перш ніж надсилати реальний запит, як GETабо POST. Розробник Backend забуває розібратися із OPTIONSзапитом, відпустивши його через код послуги, зробивши час обробки занадто довгим. Більше, ніж налаштування часу очікування, яке я записав при axiosініціалізації, що становить 5000 мілісекунд. Тому справжній запит не вдалося надіслати, і тоді я зіткнувся з provisional headers are shownпроблемою.
Рішення: Якщо мова заходить про OPTIONSзапит, бекенд-api просто повертає результат, він робить запит швидшим і реальний запит може бути відправлений перед тимчасовим очікуванням.

Я сумніваюся, що моя відповідь вчасно допоможе вам, але інші можуть вважати її корисною. У мене виникли подібні проблеми із сценарієм jQuery Ajax Post, який я створив.

Виявилося, що у мене був помилка в атрибуті href тегу A, який я використовував для звільнення посту. Я набрав href = " javacsript:; " (Зворотній зв'язок "s" і "c"). Це спричинило те, що сценарій намагався оновити сторінку під час спроби публікації. виправив друкарську помилку, і це працювало прекрасно для мене.

Це повідомлення може виникнути, коли веб-сайт захищений за допомогою HSTS . Потім, коли хтось посилається на HTTP-версію URL-адреси, браузер, згідно інструкцій HSTS, не видає HTTP-запит, а внутрішньо надійно перенаправляє на ресурс HTTPS. Це дозволяє уникнути зниження рівня HTTPS-атак, таких як sslstrip .

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

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

У моєму випадку запит було правильно надіслано на сервер, код на стороні сервера потім видав помилку, і мої власні обробки помилок повернули повідомлення про помилку в поле повідомлення про стан HTTP. Але ця помилка не була отримана на стороні клієнта через недійсні символи в повідомленні про помилку (описаний тут http://aspnetwebstack.codeplex.com/workitem/1386 ), що призвело до корумпованих заголовків відповідей.

Я зіткнувся з цим питанням за допомогою дзвінка AJAX, який ніколи не завершиться. Я дотримувався порад wvega та підказки щодо налагодження, chrome://net-internalsщоб врешті визначити іншого clickобробника подій на сторінці, прослуховуючи батьківський вузол, змусив браузер перейти до тієї ж URL-адреси (тому це було не помітно).

Рішення було додати event.stopPropagation()в clickобробник на формі кнопки відправки , щоб клацання від вирує в DOM і скасування запиту AJAX Йде (ініційований з допомогою submitобробника на form).

У мене з’явилося це зовсім недавно (фактично сьогодні), коли я мав дзвінок AJAX, виходив на сервер, а Chrome вимикає "Обережно: відображаються попередні заголовки". У сценарії PHP на сервері є запити MySQL, які можуть бути майже миттєвими або займати кілька секунд залежно від заданого сценарію. Відповідь мого сервера не надсилається назад до браузера, поки запити не будуть завершені. Я виявив, що я отримую цю помилку лише тоді, коли проводяться трудомісткі запити (загалом до декількох секунд) і запобігають надсиланню відповіді.

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

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

e.preventDefault();

або

return false;

Якщо цього не зробити, на вкладці "Мережа" веб-консолі ви побачите попереджуючі заголовки, а також статус "скасовано".

У моєму випадку це був просто хибний встановлений шлях до ресурсу (svg / img)

Ця проблема у мене виникла, коли я надсилав недійсний заголовок авторизації HTTP. Я забув базувати її base64.

Я натрапив на це, і воно пішло, коли я перейшов з https на http. Сертифікати SSL, які ми використовуємо у програмі dev, не перевіряються стороною. Вони просто локально створені розробники.

Ті самі дзвінки працюють чудово в Chrome Canary та Firefox. Ці веб-переглядачі не дуже суворі щодо SSL-версії, як Chrome. У Chrome виклики не відбудуться із повідомленням "ОБЕРЕЖНО: Тимчасові заголовки ...".

Я думаю / сподіваюсь, що коли ми будемо використовувати законний сертифікат SSL на стадії і в програмі, ми більше не побачимо такої поведінки в Chrome

Просто кинув у мене два центи. Я пишу веб-додаток, використовуючи CORS-запити та повний RESTful веб-сервіс. Я виявив, що хром видалить цю помилку, коли у мене буде викинуто безперебійне виключення або помилка PHP. Просто випадок, коли хтось інший натрапить на проблему. Я виявив, що коли це станеться, я можу запустити додаток Chrome "Листоноша - відпочиваючий клієнт" та запустити такий самий запит, але в додатку Chrome я отримаю фактично помилку PHP, яку викидають замість цієї не описової помилки.

Я запустив цю проблему, коли я вдруге намагався завантажити main.js для вимагати js після внесення змін у результаті помилки. Я щойно увімкнув у Налаштуваннях Інструментів для розробників "Вимкнути кеш (коли DevTools відкрито)". і це зробило чарівність.

Ще один можливий сценарій, який я бачив - той самий запит надсилається знову через кілька мілісекунд (швидше за все, через помилку на стороні клієнта).
У цьому випадку ви також побачите, що статус першого запиту "скасовується" і що затримка становить лише кілька мілісекунд.

Це сталося для мене, коли у мене було посилання на завантаження і після натискання на нього я намагався також вловити клацання jquery та надіслати запит на ajax. Проблема полягала в тому, що коли ви натискаєте на посилання для завантаження, ви залишаєте сторінку, навіть це не виглядає так. Якщо передачі файлів не буде, ви побачите запитувану сторінку. Тому я встановив target = "_ blank" для запобігання цієї проблеми.

Я отримав цю помилку, коли спробував надрукувати сторінку у спливаючому віці. Було показано діалогове вікно друку, і воно все ще чекає мого прийняття чи скасування друку на спливаючому вікні, а на головній сторінці також чекали на задньому плані, де відображається повідомлення ОБЕРЕЖНО попередні заголовки відображаються, коли я намагався натиснути інше посилання.

У моєму випадку рішенням було усунути window.print ();скрипт, який він виконував <body>у спливаючому вікні, щоб запобігти діалогу друку.

Я бачив, що це відбувається, коли кількість підключень до мого сервера перевищила максимальну ліміт максимальних з'єднань Chrome на сервер 6.

Скористайтеся цим кодовим кулаком свого коду:

header('Cache-Control: no-cache, no-store, must-revalidate');
header('Pragma: no-cache');
header('Expires: 0');

Це працює для мене.

Ось ще одне рішення.

Якщо ви зіткнулися з цією проблемою під час виклику $ ajax (), додайте http://до того, як ваш сервер вирішить вашу проблему.

var requestURL = "http://" + serverHost;
$.ajax({
    dataType: "json",
    url: requestURL,
    data: data,
    success: success    
});

Якщо ви розробляєте додаток Asp.Net MVC , і ви намагаєтеся повертати JsonResultв вашому контролері, переконайтеся , що ви додаєте JsonRequestBehavior.AllowGetдо Jsonметоду. Це зафіксувало це для мене.

public JsonResult GetTaskSubCategories(int id)
{
    var subcategs = FindSubCategories(id);

    return Json(subcategs, JsonRequestBehavior.AllowGet);  //<-- Notice it has two parameters
}

Попередження може бути показане, коли веб-сайт, розміщений на HTTPS, викликає дзвінки в WebApi, розміщені на HTTP. Ви можете перевірити, чи всі ваші Api - HTTPS. Браузер заважає робити дзвінки на незахищений ресурс. Ви можете бачити подібне повідомлення у своєму коді під час використання API FETCH для домену з HTTP.

Змішаний контент: Сторінка на веб- сайті " https://website.com " була завантажена через HTTPS, але запитала незахищений ресурс " http://webapi.com ". Цей запит заблоковано; вміст повинен подаватися через HTTPS.

У мене була подібна проблема з моїм додатком MEAN. У моєму випадку проблема сталася лише в одному запиті на отримання. Я спробував видалити adblock, спробував очистити кеш і спробував у різних браузерах. Ніщо не допомогло.

нарешті, я зрозумів, що api намагався повернути величезний об’єкт JSON. Коли я спробував надіслати невеликий предмет, він працював чудово. Нарешті, я змінив свою реалізацію, щоб повернути буфер замість JSON.

Я хочу, щоб expressJS помилився в цьому випадку.

Ця проблема також виникатиме під час використання деяких пакетів, таких як webpack-hot-middlewareвідкриття декількох сторінок одночасно. webpack-hot-middlewareстворить з'єднання для кожної сторінки для прослуховування змін коду, а потім оновить сторінку. Кожен веб-переглядач має max-connections-per-serverобмеження, яке становить 6 для Chrome, тому якщо ви вже відкрили більше 6 сторінок у Chrome, новий запит буде вивішений там, поки ви не закриєте деякі сторінки.

У моєму випадку причиною стало розширення AdBlock.

Запит на сервер пройшов, і я отримав відповідь, але я не міг побачити файли cookie запиту через те, що "Тимчасові заголовки .." відображаються в інструментах Dev. Після відключення AdBlock для сайту, попередження пройшло і інструменти розробки знову почали показувати файли cookie.

Щоб зміни набули чинності, потрібно було також закрити інструменти Dev та оновити сторінку