Що означає статус = скасовано для ресурсу в Інструментах для розробників Chrome?

Що може призвести до скасування сторінки? У мене є скріншот інструментів для розробників Chrome.

Це трапляється часто, але не кожен раз. Схоже, що після того, як деякі інші ресурси будуть кешовані, оновлення сторінки завантажить LeftPane.aspx. І що насправді дивно, це відбувається лише в Google Chrome, а не в Internet Explorer 8. Будь-які ідеї, чому Chrome скасує запит?

Ми боролися з подібною проблемою, коли Chrome скасовував запити на завантаження речей у рамки або рамки кадрів, але лише з перервами, і це здавалося залежним від комп'ютера та / або швидкості інтернет-з'єднання.

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

• Елемент DOM, який викликав запит, видаляється (тобто завантажується IMG, але перед тим, як відбулося завантаження, ви видалили вузол IMG)
• Ви зробили щось, що зробило завантаження даних непотрібним. (тобто ви почали завантажувати iframe, потім змінили src або перезаписали вміст)
• На один і той же сервер надходить багато запитів, і проблема з мережею на попередніх запитах показала, що наступні запити не працюватимуть (помилка пошуку DNS, попередній (той самий) запит призводила, наприклад, код помилки HTTP 400 тощо)

У нашому випадку ми нарешті простежили його до одного кадру, намагаючись додати HTML до іншого кадру, що іноді траплялося ще до того, як кадр призначення навіть завантажився. Після дотику до вмісту iframe він більше не може завантажувати в нього ресурс (як би він знав, куди його поставити?), Щоб він скасував запит.

status = скасовано може статися також на запитах ajax у подіях JavaScript:

<script>
  $("#call_ajax").on("click", function(event){
     $.ajax({
        ...    
     });
  });
</script>

<button id="call_ajax">call</button> 

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

Щоб запобігти скасуванню запиту, JavaScript event.preventDefault (); повинні бути викликані:

<script>
  $("#call_ajax").on("click", function(event){
     event.preventDefault();
     $.ajax({
        ...    
     });
  });
</script>

Примітка. Переконайтеся, що у вас немає елементів форми для обгортання .

У мене була подібна проблема, коли моя кнопка з onclick = {} була загорнута у елемент форми. Після натискання кнопки форма також подається, і це все переплутало ...

Цю відповідь, мабуть, ніхто не прочитає, але я зрозумів, чому б не написати її :)

Інша річ, на яку слід звернути увагу, може бути розширення AdBlock або розширення загалом.

Але "багато" людей мають AdBlock ....

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

Ви можете перевірити тег заголовка "Параметри X-Frame". Якщо його встановлено на SAMEORIGIN або DENY, Chrome і інші браузери скасують вставку iFrame за специфікацією .

Також зауважте, що деякі веб-переглядачі підтримують налаштування ALLOW-FROM, але Chrome це не робить.

Щоб вирішити це, вам потрібно буде видалити тег заголовка "Параметри X-Frame". Це може залишити вас відкритими для атак на кліки, тому вам потрібно буде вирішити, які ризики є, і як їх зменшити.

У моєму випадку я виявив, що це глобальні налаштування часу очікування jquery, глобальний тайм-аут встановлення плагінів jquery до 500 мс, так що коли запит перевищує 500 мс, хром скасує запит.

Ось що сталося зі мною: сервер повертав неправильно сформований заголовок "Місцезнаходження" для переадресації 302. Chrome, звичайно, мені цього не сказав. Я відкрив сторінку у firefox і одразу виявив проблему. Приємно мати кілька інструментів :)

Ще одне місце, у якому ми стикалися зі (canceled)статусом, - це конкретна неправильна конфігурація сертифіката TLS. Якщо такий веб-сайт https://www.example.comнеправильно налаштований таким чином, що сертифікат не містить, www.але він дійсний для https://example.com, chrome скасує цей запит і автоматично перенаправить на останній сайт. Це не так для Firefox.

Діючий приклад: https://www.pthree.org/

Скасований запит трапився зі мною під час переадресації між захищеними та незахищеними сторінками на окремих доменах у межах рамки. Перенаправлений запит показав у інструментах розробників як "скасований" запит.

У мене є сторінка з iframe, що містить форму, розміщену в моєму платіжному шлюзі. Коли форма в iframe була подана, шлюз платежів буде перенаправлений назад до URL-адреси на моєму сервері. Нещодавно переспрямування перестало працювати і замість цього вийшло "скасований" запит.

Здається, що Chrome (я використовував Windows 7 Chrome 30.0.1599.101) більше не дозволяв переадресацію в рамках iframe переходити на незахищену сторінку на окремому домені. Щоб виправити це, я просто переконався, що будь-які перенаправлені запити в iframe завжди надсилалися для захисту URL-адрес.

Коли я створив простішу тестову сторінку з лише рамкою, на консолі з’явилося попередження (яке я попередньо пропустив або, можливо, не з’явився):

[Blocked] The page at https://mydomain.com/Payment/EnterDetails ran insecure content from http://mydomain.com/Payment/Success

Переадресація перетворилася на скасований запит у Chrome на ПК, Mac та Android. Я не знаю, чи це стосується налаштування мого веб-сайту (низький профіль SagePay) чи щось змінилося в Chrome.

Версія Chrome 33.0.1750.154 м послідовно скасовує завантаження зображень, якщо я використовую мобільну емуляцію, вказану на мій локальний господар; в зокрема , з User Agent підміни на (проти всього екрану налаштувань).

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

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

• Прийміть
• Кеш-контроль
• Прагма
• Референт
• Користувач-агент

В останньому випадку всі ці плюс інші люблять:

• Печиво
• З'єднання
• Господар
• Прийняти-кодувати
• Прийняти мову

Потиснути плечима

Я отримав цю помилку в Chrome, коли я переспрямований через JavaScript:

<script>
    window.location.href = "devhost:88/somepage";
</script>

Як бачите, я забув "http: //" . Після того, як я додав його, це спрацювало.

У моєму випадку я мав якір із подією на кліка

<a href="" onclick="somemethod($index, hour, $event)">

Всередині події клацання у мене був якийсь мережевий дзвінок, Chrome скасовував запит. Якір має hrefз ""допомогою, він перезавантажує сторінку і в той же час він має натисніть подія з мережевим викликом , який отримує скасований. Кожен раз, коли я заміню hrefнічим подібне

<a href="javascript:void(0)" onclick="somemethod($index, hour, $event)">

Проблема пішла!

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

Коротше кажучи,
авторизований сертифікат, який не довіряють моєму телефону Android.

Деталі
Ми перебуваємо у стадії розробки / налагодження. URL вказує на власного підпису хоста. Код виглядає так:

location.href = 'https://some.host.com/some/path'

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

Якщо ви використовуєте такі запити HTTP на основі спостережуваних даних, як ті, що вбудовані в Angular (2+), запит HTTP може бути скасований, коли спостерігається скасовується (звичайна річ, коли switchMapдля комбінації потоків використовується оператор RxJS 6 ) . У більшості випадків досить використовувати mergeMapоператор, якщо ви хочете, щоб запит був завершений.

У мене було саме те саме з двома файлами CSS, які зберігалися в іншій папці поза моєю основною папкою css. Я використовую Expression Engine і виявив, що проблема була в правилах у моєму файлі htaccess. Я просто додав папку до однієї зі своїх умов, і вона її виправила. Ось приклад:

RewriteCond %{REQUEST_URI} !(images|css|js|new_folder|favicon.ico)

Тому, можливо, варто перевірити файл htaccess на наявність можливих конфліктів

Я вбудував усі типи шрифту, а також woff , woff2 , ttf, коли я вставляв веб-шрифт у таблицю стилів. Нещодавно я помітив, що Chrome скасовує запит на ttf та woff, коли woff2 присутній. Я зараз використовую версію Chrome 66.0.3359.181, але я не впевнений, коли Chrome почав скасовувати додаткові типи шрифтів.

У нас була ця проблема, маючи тег <button>у формі, яка мала надіслати запит ajax від js. Але цей запит було скасовано через браузер, який автоматично надсилає форму будь-яким клацанням buttonвсередині форми.

Отже, якщо ви дійсно хочете використовувати button замість звичайної divабо spanна сторінці, а ви хочете надіслати js форми кидання - вам слід налаштувати слухача з preventDefaultфункцією.

напр

$('button').on('click', function(e){

    e.preventDefault();

    //do ajax
    $.ajax({

     ...
    });

})

трапилось зі мною те саме, коли дзвонив. js файл з $. ajax, і зробити запит на ajax, я звичайно дзвонив.

У моєму випадку код, який відображав вікно клієнта електронної пошти, змусив Chrome припинити завантаження зображень:

document.location.href = mailToLink;

переміщення його в $ (window) .load (функція () {...}) замість $ (function () {...}) допомогло.

Чи може це допомогти будь-кому, хто зіткнувся зі скасованим статусом, коли я залишив помилку повернення; у формі подати. Це спричинило негайне відправлення ajax після дії надсилання, яка перезаписала поточну сторінку. Код показаний нижче, важливе повернення помилково в кінці.

$('form').submit(function() {

    $.validator.unobtrusive.parse($('form'));
    var data = $('form').serialize();
    data.__RequestVerificationToken = $('input[name=__RequestVerificationToken]').val();

    if ($('form').valid()) {
        $.ajax({
            url: this.action,
            type: 'POST',
            data: data,
            success: submitSuccess,
            fail: submitFailed
        });
    }
    return false;       //needed to stop default form submit action
});

Сподіваюся, що хтось допомагає.

Для тих, хто приходить з LoopbackJS та намагається використовувати спосіб користувальницького потоку, як зазначено у прикладі їх діаграми. Я отримував цю помилку за допомогою PersistedModel, переключившись на основну Modelвиправлену проблемуeventsource скасування статусу.

Знову ж таки, це спеціально для циклу api. А оскільки це найкраща відповідь, а в Google - я зрозумів, що я кидаю це в поєднання відповідей.

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

• створити кадр

• при завантаженні iframe надішліть форму

• Через 2 секунди зніміть кадр iframe

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

Для мене статус "скасований" був тому, що файл не існував. Дивно, чому хром не проявляється 404.

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

Запити можуть бути заблоковані плагіном захисту відстеження.

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

Однією з причин може бути те, що XMLHttpRequest.abort () викликався десь у коді, у цьому випадку запит матиме cancelledстатус на вкладці Мережі інструментів розробника Chrome.

У моєму випадку вона почала надходити після оновлення chrome 76.

Через якусь проблему в моєму JS-коді window.location оновлювався кілька разів, що призвело до скасування попереднього запиту. Незважаючи на те, що проблема існувала раніше, компанія Chrome почала скасовувати запит після оновлення до версії 76.

У мене був той самий випадок, коли оновлювався запис. Всередині save () я готував попередні дані, взяті з форми, щоб відповідати формату бази даних (роблячи багато відображення значень перерахувань тощо), і це переривчасто скасовує запит put. Я вирішив це, вийнявши підготування даних із збереження () та створивши з нього виділений метод dataPrep (). Я перетворив цей dataPrep в асинхронність і чекаю всієї конверсії даних, що потребує великої пам'яті. Потім я повертаю попередньо підготовлені дані до методу save (), який я міг би використовувати в клієнтові http put. Я переконався, що чекаю на dataPrep (), перш ніж викликати метод put:

очікувати dataToUpdate = очікувати dataPrep (); http.put (apiUrl, dataToUpdate);

Це вирішило переривчасте скасування запиту.

Якщо ви використовуєте axios, це може вам допомогти

// change timeout delay: instance.defaults.timeout = 2500;

https://github.com/axios/axios#config-order-of-precedence