Запити jQuery Ajax скасовуються без надсилання

Я намагаюся підключити скрипт до програми Microsoft World Wide Telescope. Останній слухає на порту 5050 команди. Він працює на тій самій машині, що і браузер (Chrome зараз, але, наскільки я можу зрозуміти, поведінка однакова з Firefox 7 та IE 9).

Я надсилаю заголовок "Access-Control-Allow-Origin: *" із оригінальним файлом html, щоб спробувати усунути обмеження XSS як свою проблему.

Мій код для доступу до WWT такий:

$.ajax({
    type: 'POST',
    url: url,
    data: data,
    crossDomain: true,
    success: success,
    dataType: dataType
});

url в цьому випадку - "http: //127.0.0.1: 5050 / layerApi.aspx? cmd = new & ..." (очевидно ... тут це скорочення для деяких додаткових параметрів).

Переглядаючи діагностику мережі в Chrome, я бачу це:

Request URL:http://127.0.0.1:5050/layerApi.aspx?cmd=new&...
Request Headersview source
Accept:application/xml, text/xml, */*; q=0.01
Content-Type:application/x-www-form-urlencoded
Origin:http://gwheeler4
Referer:http://gwheeler4/conceptconnect.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.186 Safari/535.1

Запит виходить - я бачу, як WWT робить новий шар. Однак я не отримую зворотного дзвінка. Якщо я додаю зворотний виклик помилки, який викликається, але властивість помилки в об'єкті jqXHR - це просто "помилка", а статус - 0. Якщо я подивлюся на мережевий запит у Chrome, я бачу "(скасовано)" як стан і відсутність відповіді .

Якщо я візьму ту саму URL-адресу та вставлю її на нову вкладку браузера, я побачу, що відповідь - це очікуваний XML.

Звичайно, різниця тут полягає в тому, що це GET, а не POST, але я спробував це в своєму сценарії, і це не має ніякої різниці.

Мене це дуже бентежить і буду вдячний за будь-які нові ідеї.

Якщо хтось ще стикається з цим, проблема у нас була в тому, що ми робимо запит ajax за посиланням і не заважаємо переходу за посиланням. Тож якщо ви робите це в onclickатрибуті, переконайтеся return false;також.

Якщо ви використовуєте Chrome, ви не бачите достатньо інформації на стандартній мережевій панелі Chrome, щоб визначити першопричину (canceled)запиту.

Вам потрібно використовувати, chrome://net-internals/#eventsякий покаже вам детальну інформацію про запит, який ви відправляєте, включаючи приховані переадресації / інформацію про безпеку надсиланих файлів cookie тощо.

наприклад, нижче показано перенаправлення, яке я не бачив у мережевій трасі - спричинене тим, що мої файли cookie не надсилаються між субдоменами:

t=1374052796448 [st=  1]   +URL_REQUEST_START_JOB  [dt=261]
                            --> load_flags = 143540481 (DO_NOT_SAVE_COOKIES | DO_NOT_SEND_AUTH_DATA | DO_NOT_SEND_COOKIES | ENABLE_LOAD_TIMING | MAYBE_USER_GESTURE | REPORT_RAW_HEADERS | VALIDATE_CACHE | VERIFY_EV_CERT)
                            --> method = "GET"
                            --> priority = 2
                            --> url = "https://...."
...
t=1374052796708 [st=261]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                                --> HTTP/1.1 302 Moved Temporarily
                                    Content-Type: text/html
                                    Date: Wed, 17 Jul 2013 09:19:56 GMT
...
t=1374052796709 [st=262]     +URL_REQUEST_BLOCKED_ON_DELEGATE  [dt=0]
t=1374052796709 [st=262]        CANCELLED
t=1374052796709 [st=262]   -URL_REQUEST_START_JOB
                            --> net_error = -3 (ERR_ABORTED)

У моєму випадку у мене це було, type='submit'коли я подавав форму, сторінка перезавантажувалась до того, як вдарив ajax, тому було просте рішення type="button". Якщо ви не вказали тип, це submitза замовчуванням, тому вам потрібно вказатиtype="button"

type='submit' => type='button'

АБО

Немає типу => type='button'

У мене була подібна проблема. У моєму випадку я намагаюся використовувати веб-службу на сервері apache + django (послугу написав я сам). У мене був такий самий результат, як у вас: Chrome каже, що його було скасовано, тоді як FF робить це нормально. Якби я спробував отримати доступ до служби безпосередньо у браузері замість ajax, це також працювало б. Погугливши, я виявив, що деякі новіші версії apache неправильно встановлювали довжину відповіді в заголовках відповідей, тому я зробив це вручну. З django мені потрібно було лише:

response['Content-Length'] = len(content)

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

У мене була подібна проблема. Використовуючи chrome: // net-internals / # events, я зміг побачити, що моя проблема виникла внаслідок якогось безшумного перенаправлення. Мій запит на отримання було запущено в скрипті onload. URL-адреса мала форму " http://example.com/inner-path ", а 301 постійно переспрямовувала на "/ внутрішній шлях". Щоб виправити проблему, я просто змінив URL-адресу на "/ internal-path", і це вирішило проблему. Я досі не знаю, чому сценарій, який працював тиждень тому, раптом видав мені проблему ... Сподіваюся, це комусь допомагає

(Використання веб-форм ASP.NET)

Моя проблема полягала в тому, що я намагався звільнити Ajax від події натискання кнопки надсилання, яка мала налаштування події натискання на стороні сервера. Мені довелося зробити кнопку простою кнопкою (тобто <input type="button">)

У мене була та ж проблема, для мене я тимчасово створював iframe і видаляв iframe до того, як ajax стане завершеним, тому браузер скасує мій запит ajax.

Розширюючи відповідь @ Kazetsukai, ви можете зіткнутися з цією проблемою, якщо робите запит AJAX від користувача, натискаючи посилання.

Якщо ви встановили посилання приблизно так:

<a href="#" onclick="soAjax()">click me!</a>

А потім обробник javascript, такий як:

soAjax() {
    $.ajax({ ... all your lovely parameters ... });       
}

Щоб ваш браузер не переходив за посиланням і не скасовував будь-які запити, що виконуються, слід додати return falseабо e.preventDefault()зупинити розповсюдження події кліку:

soAjax() {
   $.ajax({ ... etc ... });
   return false;
}

Або:

soAjax(e) {
   $.ajax({ ... etc ... });
   e.preventDefault();
}

Існує дві можливості, коли запит AJAX відхиляється (якщо не запит про перехресне походження):

1. Ви не заважаєте поведінці елемента за замовчуванням для події.
2. Ви встановили тайм-аут AJAX занадто низьким, або внутрішній сервер мережі / програми працює повільно.

Рішення для 1) : додайте return false;або e.preventDefault();в обробник події.

Рішення для 2) : додайте параметр тайм-ауту під час формування запиту AJAX. Приклад нижче.

$.ajax({
    type: 'POST',
    url: url,
    timeout: 86400,
    data: data,
    success: success,
    dataType: dataType
});

Для запитів про перехресне походження перевірте заголовки HTTP для спільного використання ресурсів (CORS).

Я отримав цю помилку під час надсилання запиту за допомогою http на URL-адресу, яка вимагає https. Я думаю, виклик ajax не обробляє перенаправлення. Це має місце навіть у випадку, коли для параметра ajax crossDomain встановлено значення true (на JQuery 1.5.2).

У моєму випадку я переписав моду Apache, відповідаючи URL-адресі та перенаправляючи запит на https.

Подивіться на запит у chrome: // net-internals / # events.

Він покаже внутрішній журнал запиту. Перевірте наявність переспрямувань.

У мене була та сама проблема, але в моєму випадку це виявилося проблемою cookie. Хлопці, які працювали на задній панелі, змінили шлях до файлу cookie JSESSIONID, який встановлюється, коли ми входимо в наш додаток, і на моєму комп’ютері у мене був старий файл cookie з таким ім’ям, але зі старим шляхом. Отже, коли я спробував увійти в браузер (Chrome), надіслав на сервер два файли cookie з назвою JSESSIONID з різними значеннями - що зрозуміло його збило з пантелику - тому він скасував запит. Видалення файлів cookie з мого комп’ютера це виправило.

У мене була ця помилка більш моторошним способом: вкладка мережі та події chrome: // net-internals / # не відображали запит після завершення js. При призупиненні js під час виклику помилок на вкладці мережі відображався запит як (скасовано). Постійно вимагався рівно один (завжди однаковий) з декількох подібних запитів на веб-сторінці. Після перезапуску Chrome помилка більше не виникала!

Я скасував у Firefox . Деякі дзвінки ajax для мене працюють цілком нормально, але це не вдалося для колеги, яка насправді мала його використовувати.

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

Рішення було дуже простим: перейти до історії, знайти веб-сайт, клацнути правою кнопкою миші -> забути веб-сайт.
Забудьте, а не видаліть.

Після цього вже ніяких проблем. Я гадаю, це пов’язано з .htaccess.

У моєму випадку це була відсутність косої риски в URL-адресі. Додавання кінцевої риски вирішило мою проблему.

Для випадку Dropzone.js. У моєму випадку це було викликано через те, що значення timeoutпараметра було занизьким за замовчуванням. Тож збільште його на свої потреби.

{
// other dropzone options
timeout: 60000 * 10, // 10 minutes
...
}

У мене виникла проблема з певною мережею 3G.
Завжди не вдається видалити запити з net_error = -101chrome: // net-internals / # events.

Інші мережі працювали нормально, тому я припускаю, що був несправний проксі-сервер або щось інше.