Что приведет к отмене страницы? У меня есть скриншот из инструментов разработчика Chrome.
Это происходит часто, но не каждый раз. Кажется, что, как только некоторые другие ресурсы будут кэшироваться, обновление страницы загрузит LeftPane.aspx. И что действительно странно, это происходит только в Google Chrome, а не в Internet Explorer 8. Любые идеи, почему Chrome отменит запрос?
Мы столкнулись с аналогичной проблемой, когда Chrome отменял запросы на загрузку вещей в рамках фреймов или iframe, но только с перерывами и, казалось, зависел от компьютера и/или скорости интернет-соединения.
Эта информация за несколько месяцев устарела, но я построил Chromium с нуля, вырыл источник, чтобы найти все места, где запросы могли быть отменены, и ударил точки останова на всех из них для отладки. Из памяти - единственные места, где Chrome отменит запрос:
В нашем случае мы, наконец, проследили его до одного кадра, пытаясь добавить HTML в другой фрейм, который иногда случался до того, как кадр назначения даже загрузился. Как только вы касаетесь содержимого iframe, он больше не может загружать в него ресурс (как он узнает, куда его поместить?), Поэтому он отменяет запрос.
status = cancel может также произойти также в запросах 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 = {} была обернута в элемент формы. При нажатии кнопки форма также отправляется, и это все испортило...
Этот ответ, вероятно, никогда не будет прочитан кем-либо, но я подумал, почему бы не написать его:)
Возможно, вы захотите проверить тег заголовка "X-Frame-Options". Если его установить в SAMEORIGIN или DENY, то вставка iFrame будет отменена браузером Chrome (и другими браузерами) в .
Также обратите внимание, что некоторые браузеры поддерживают параметр ALLOW-FROM, но Chrome этого не делает.
Чтобы решить эту проблему, вам необходимо удалить тег заголовка "X-Frame-Options". Это может оставить вас открытыми для атак с кликнированием, поэтому вам нужно будет решить, какие риски и как их смягчить.
Еще одна вещь, на которую можно обратить внимание, может быть расширение AdBlock или расширение в целом.
Но у "много" людей есть AdBlock....
Чтобы исключить расширение (ы), откройте новую вкладку в инкогнито, убедившись, что "разрешить в инкогнито отключено" для расширений, которые вы хотите проверить.
В моем случае я обнаружил, что это параметры глобального тайм-аута jquery, установление глобального тайм-аута jQuery для глобального тайм-аута до 500 мс, так что, когда запрос превышает 500 мс, хром отменит запрос.
Вот что случилось со мной: сервер возвращал неверный заголовок "Location" для перенаправления 302. Хром, конечно, не сказал мне об этом. Я открыл страницу в firefox и сразу обнаружил проблему. Приятно иметь несколько инструментов:)
Отмененный запрос произошел со мной при перенаправлении между безопасными и незащищенными страницами в отдельных доменах в iframe. Перенаправленный запрос показал в инструментах dev как "отмененный" запрос.
У меня есть страница с 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 Low Profile) или если что-то изменилось в Chrome.
Еще одно место, где мы столкнулись с (canceled), - это некорректная конфигурация сертификата TLS. Если сайт, такой как https://www.example.com, неправильно сконфигурирован таким образом, что сертификат не включает www., но действителен для https://example.com, хром отменит этот запрос и автоматически перенаправит его на последний сайт. Это не относится к Firefox.
В настоящее время действительный пример: https://www.pthree.org/
Chrome Version 33.0.1750.154 m последовательно отменяет загрузку изображений, если я использую Мобильная эмуляция, указанную на моем localhost; в частности, с помощью подменю User Agent (в отличие от настроек экрана).
Когда я отключу спуфинг User Agent; запросы изображений не отменены, я вижу изображения.
Я до сих пор не понимаю, почему; в первом случае, когда запрос отменяется заголовками запроса (ПРЕДУПРЕЖДЕНИЕ: предварительные заголовки показаны) имеют только
В последнем случае все из них плюс другие, такие как:
Shrug
У меня было то же самое с двумя файлами CSS, которые были сохранены в другой папке вне моей основной папки css. Я использую Expression Engine и обнаружил, что проблема была в правилах в моем файле htaccess. Я просто добавил папку в одно из моих условий и исправил ее. Вот пример:
RewriteCond %{REQUEST_URI} !(images|css|js|new_folder|favicon.ico)
Поэтому, возможно, стоит проверить файл htaccess на наличие каких-либо потенциальных конфликтов.
Я получил эту ошибку в Chrome, когда перенаправляю через JavaScript:
<script>
window.location.href = "devhost:88/somepage";
</script>
Как вы видите , я забыл "http://" . После того, как я добавил его, он сработал.
Для моего случая у меня был якорь с событием click, например
<a href="" onclick="somemethod($index, hour, $event)">
Внутри события кликов у меня был сетевой вызов, Chrome отменил запрос. Якорь имеет href со значением "", он перезагружает страницу и одновременно имеет событие click с сетевым вызовом, который отменяется. Всякий раз, когда я заменяю href на void как
<a href="javascript:void(0)" onclick="somemethod($index, hour, $event)">
Проблема исчезла!
Я включил все типы шрифтов, а также woff, woff2, ttf, когда я вставляю веб-шрифт в таблицу стилей. Недавно я заметил, что Chrome отменяет запрос на ttf и woff, когда присутствует woff2. Я использую Chrome версии 66.0.3359.181 прямо сейчас, но я не уверен, когда Chrome начал отменять дополнительные типы шрифтов.
У нас возникла проблема с тегом <button> в форме, который должен был отправить запрос ajax из js. Но этот запрос был отменен из-за браузера, который отправляет форму автоматически при нажатии button внутри формы.
Поэтому, если вы действительно хотите использовать button вместо обычного div или span на странице, и вы хотите отправить форму throw js - вы должны настроить прослушиватель с функцией preventDefault.
например
$('button').on('click', function(e){
e.preventDefault();
//do ajax
$.ajax({
...
});
})
Вот еще один случай, когда Chrome отменял запрос, с которым я только что столкнулся, и на который нет ответов.
В двух словах
Самоподписанный сертификат не является доверенным на моем телефоне Android.
подробности
Мы находимся в стадии разработки/отладки. URL-адрес указывает на самоподписанный хост. Код похож на:
location.href = 'https://some.host.com/some/path'
Chrome просто отменил запрос молча, не оставив новичка в веб-разработке, как я, чтобы решить эту проблему. После того, как я скачал и установил сертификат с помощью телефона Android, проблема исчезла.
случилось со мной то же самое при вызове a. js файл с $. ajax и сделать запрос ajax, то, что я сделал, было нормально.
В моем случае код, отображающий окно клиента электронной почты, заставил Chrome перестать загружать изображения:
document.location.href = mailToLink;
переместив его в $(window).load(function() {...}) вместо $(function() {...}).
В этом может помочь кто-нибудь, с кем я столкнулся с отмененным статусом, когда я оставил неверное значение return; в форме 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 и пытается использовать метод пользовательского потока, как показано в их графическом примере. Я получил эту ошибку, используя PersistedModel, перейдя на базовый Model исправленный вопрос о статусе отмены eventsource.
Опять же, это специально для loopback api. И так как это верный ответ и верх над google, я решил, что я это сделаю в сочетании ответов.
Я столкнулся с той же проблемой, где-то в глубине нашего кода у нас был этот псевдокод:
onload iframe отправить форму
Через 2 секунды удалите iframe
Таким образом, когда сервер занимает более 2 секунд, чтобы ответить на iframe, на который сервер писал ответ, был удален, но ответ еще должен был быть написан, но не было iframe для записи, поэтому chrome отменен запрос, чтобы избежать этого, я убедился, что iframe удаляется только после завершения ответа или вы можете изменить цель на "_blank". Таким образом, одна из причин: , когда ресурс (iframe в моем случае), в котором вы что-то пишете, удаляется или удаляется, прежде чем вы перестанете писать на него, запрос будет отменен
Для меня статус "отменен" был вызван тем, что файл не существовал. Странно, почему хром не показывает 404.
Это было так же просто, как неправильный путь для меня. Я бы предположил, что первым шагом в отладке было бы увидеть, можете ли вы загрузить файл независимо от ajax и т.д.
Запросы могли быть заблокированы плагином для отслеживания.
Это случилось со мной при загрузке 300 изображений в качестве фоновых изображений. Я предполагаю, что однажды первый тайм-аут, он отменил все остальные или достиг максимального числа одновременных запросов. необходимо реализовать 5 за один раз
Одной из причин может быть то, что XMLHttpRequest.abort() был вызван где-то в коде, в этом случае запрос будет иметь cancelled статус на вкладке Сеть инструментов разработчика Chrome.