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

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

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

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

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

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

  call 

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

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

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

Также обратите внимание, что некоторые браузеры поддерживают параметр ALLOW-FROM, но Chrome этого не делает.

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

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

Но «много» людей имеет AdBlock ….

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

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

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

Этот ответ, вероятно, никогда не будет прочитан кем-либо, но я подумал, почему бы не написать его 🙂

Вот что случилось со мной: сервер возвращал неверный заголовок «Location» для перенаправления 302. Хром, конечно, не сказал мне об этом. Я открыл страницу в firefox и сразу обнаружил проблему. Приятно иметь несколько инструментов 🙂

В моем случае я обнаружил, что это параметры глобального тайм-аута jquery, jQuery-плагин устанавливает глобальный тайм-аут на 500 мс, так что, когда запрос превышает 500 мс, хром отменит запрос.

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

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

Кажется, что Chrome (я использовал Windows 7 Chrome 30.0.1599.101) больше не разрешал redirect внутри 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 Low Profile) или если что-то изменилось в Chrome.

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

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

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

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

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

Chrome Version 33.0.1750.154 m последовательно отменяет загрузку изображений, если я использую мобильную эмуляцию, указанную на моем локальном хосте; в частности, с помощью спуфинга User Agent (по сравнению с настройками экрана).

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

Я до сих пор не понимаю, почему; в первом случае, когда запрос отменяется заголовками запроса (ПРЕДУПРЕЖДЕНИЕ: показаны предварительные заголовки), только

• принимать
• Cache-Control
• Pragma
• Referer
• User-Agent

В последнем случае все из них плюс другие:

• печенье
• соединение
• хозяин
• Accept-Encoding
• Accept-Language

пожимание плечами

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

Как вы видите, я забыл «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 () {…}) вместо $ (function () {…}).

In can это помогает любому, кому я сталкивался с отмененным статусом, когда я не учитывал возврат false; в форме submit. Это вызвало немедленное отправление ajax-отправления действием отправки, которое перезаписало текущую страницу. Код показан ниже, с важным возвратом 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 и пытается использовать метод пользовательского streamа, как показано в их графическом примере. Я получал эту ошибку с помощью PersistedModel , переключившись на базовую Model исправил мою проблему eventsource статуса источника eventsource .

Опять же, это специально для loopback api. И так как это верный ответ и верх над google, я решил, что я брошу это в сочетании ответов.

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

• создать iframe

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

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

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

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

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

Проблема исчезла!

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