Что означает status=cancelled для ресурса в инструментах разработчика Chrome?

Что может привести к отмене страницы? У меня есть скриншот инструментов разработчика Chrome.

Canceled Resource

Это происходит часто, но не каждый раз. Похоже, что после кэширования некоторых других ресурсов обновление страницы загрузит левую панель.аспн. И что действительно странно, это происходит только в Google Chrome, а не Internet Explorer 8. Есть идеи, почему Chrome отменит запрос?

21 ответов


мы боролись с аналогичной проблемой, когда Chrome отменял запросы на загрузку вещей в кадрах или iframes, но только периодически, и это, казалось, зависело от компьютера и/или скорости подключения к интернету.

эта информация устарела на несколько месяцев, но я построил Chromium с нуля, прокопал источник, чтобы найти все места, где запросы могут быть отменены, и ударил точки останова на всех из них для отладки. Из памяти, единственные места, где Chrome отменит запрос:

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

в нашем случае мы, наконец, проследили его до одного кадра, пытаясь добавить HTML к другому кадру, что иногда происходило до загрузки целевого кадра. Как только вы коснетесь содержимого iframe, он больше не сможет загружать в него ресурс (как он узнает, куда его поместить?) таким образом, он отменяет запрос.


status=cancelled может произойти также в ajax-запросах на JavaScript-событиях:

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

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

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

чтобы предотвратить отмену запроса, событие JavaScript.preventDefault (); должен быть вызван:

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

возможно, вы захотите проверить тег заголовка "X-Frame-Options". Если его значение равно SAMEORIGIN или DENY, то вставка iFrame будет отменена Chrome (и другими браузерами) за spec.

кроме того, обратите внимание, что некоторые браузеры поддерживают параметр "Разрешить", но Chrome этого не делает.

чтобы решить эту проблему, вам нужно будет удалить тег заголовка "X-Frame-Options". Это может оставить вас открытыми для clickjacking атак поэтому вам нужно решить, что риски есть и как их снизить.


еще одна вещь, на которую нужно обратить внимание, может быть расширение AdBlock или расширения в целом.

но "много" людей имеют AdBlock....

чтобы исключить расширение(ы), откройте новую вкладку в инкогнито, убедившись, что "разрешить инкогнито выключено" для расширения(ОВ), которое вы хотите проверить.


NB: убедитесь, что у вас нет любые элементы формы обертывания.

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

этот ответ, вероятно, никогда не будет прочитан всеми, но я подумал, почему бы не написать это :)


вот что случилось со мной: сервер возвращал искаженный заголовок "Location" для перенаправления 302. Конечно, Chrome не сказал мне об этом. Я открыл страницу в Firefox, и сразу обнаружил проблему. Приятно иметь несколько инструментов:)


в моем случае я обнаружил, что это jQuery global timeout settings, jQuery plugin setup global timeout to 500ms, так что, когда запрос превышает 500ms, chrome отменит запрос.


отмененный запрос произошел со мной при перенаправлении между защищенными и незащищенными страницами на отдельных доменах в iframe. Перенаправленный запрос отображается в dev tools как "отмененный" запрос.

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

Кажется, что Chrome (я использовал Windows 7 Chrome 30.0.1599.101) больше не разрешал перенаправление в iframe для перехода на небезопасную страницу в отдельном домене. Чтобы исправить это, я просто убедился, что любые перенаправленные запросы в iframe всегда отправляются в безопасные URL-адреса.

когда я создал более простую тестовую страницу только с iframe, в консоли было предупреждение (которое я ранее пропустил или, возможно, не появился):

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

перенаправление превратилось в отменен запрос в Chrome на ПК, Mac и Android. Я не знаю, связано ли это с настройкой моего сайта (низкий профиль SagePay) или что-то изменилось в Chrome.


еще одно место, где мы столкнулись с (canceled) статус находится в определенной неправильной конфигурации сертификата TLS. Если такой сайт, как https://www.example.com неправильно настроен так, что сертификат не включает www. но действует https://example.com, chrome отменит этот запрос и автоматически перенаправит его на последний сайт. Это не случай для Firefox.

в настоящее время допустимый пример:https://www.pthree.org/


У меня было то же самое с двумя файлами CSS, которые хранились в другой папке за пределами моей основной папки css. Я использую Expression Engine и обнаружил, что проблема была в правилах в моем файле htaccess. Я просто добавил папку в одно из моих условий, и он исправил его. Вот пример:

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

поэтому, возможно, стоит проверить файл htaccess на наличие потенциальных конфликтов


Chrome версии 33.0.1750.154 M последовательно отменяет загрузку изображений, Если я использую Мобильная Эмуляция указал на мой localhost; в частности, с спуфинг агента пользователя on (против просто настроек экрана).

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

Я до сих пор не понимаю, почему; в первом случае, когда запрос отменяется заголовки запроса (внимание: предварительный заголовки показаны) имеют только

  • принимать
  • Кэш-Контроля
  • Прагма
  • заголовок
  • User-Agent

в последнем случае, все эти плюс другие подобные:

  • Cookie
  • подключение
  • Хоста
  • Accept-Encoding
  • Принять-Язык

пожав


Я получил эту ошибку в Chrome при перенаправлении через JavaScript:

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

Как видите,Я забыл " http://". После того, как я добавил его, это сработало.


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


случилось со мной то же самое при вызове. файл js с $. ajax, и сделать запрос ajax, что я сделал, это позвонить нормально.


в моем случае код для отображения окна почтового клиента заставил Chrome прекратить загрузку изображений:

document.location.href = mailToLink;

перемещение в $(window).load(function () {...}) вместо $(функция () {...}) помогший.


в can это помогает любому, с кем я столкнулся с отмененным статусом, когда я пропустил возврат false; в форме submit. Это заставило ajax send немедленно следовать за действием submit, которое перезаписало текущую страницу. Код показан ниже, с важным возвращением false в конце.

$('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 loopback. И поскольку это лучший ответ и топ в google, я решил, что я брошу это в смесь ответов.


Я столкнулся с той же проблемой, где-то глубоко в нашем коде у нас был этот псевдокод:

  • создать iframe
  • onload iframe отправить форму

  • через 2 секунды удалите iframe

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


для моего случая у меня был якорь с событием click, как

<a href="" (click)="onClick($index, hour, $event)">

внутри события щелчка у меня был какой-то сетевой вызов, chorme отменил запрос. Якорь href С "" означает попытку пройти начальный (пустой) маршрут и в то же время он имеет событие щелчка с сетевым вызовом!! Всякий раз, когда я заменяю href с пустотой, как

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

проблема ушла!


для меня статус отменен был, потому что файл не существует. Странно, почему chrome не показывает 404.


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