Що це означає, коли запит HTTP повертає код статусу 0?

Що це означає, коли виклики мережі JavaScript, такі як отримання або XMLHttpRequest, або будь-який інший тип мережевого запиту HTTP, не спрацьовують із кодом статусу HTTP 0?

Здається, це не дійсний код статусу HTTP, оскільки інші коди - це три цифри у специфікації HTTP.

Я спробував повністю відключити мережу як тест. Це може бути не пов’язано, але це призвело до коду статусу 17003 (IIRC), який побіжний пошук підказує означає "невдалий пошук сервера DNS".

Цей же код добре працює в деяких місцях і системах, однак у певних середовищах він не працює з кодом статусу 0 і не передбачено відповідіText.

Це типовий HTTP POST для Інтернет-адреси. Він не включає файл: // який, наскільки я розумію, може повернути 0, що вказує на успіх у Firefox.

Я вважаю, що код помилки вказує на те, що відповідь була порожньою (оскільки не було повернуто навіть заголовків). Це означає, що з'єднання було прийнято, а потім витончено закрите (TCP FIN). Існує ряд речей, які можуть спричинити це, але, виходячи з вашого опису, деяка форма брандмауера здається найбільш ймовірним винуватцем.

Багато відповідей тут неправильні. Здається, люди з'ясовують, що викликало статус == 0 у конкретному випадку, а потім узагальнюють це як відповідь.

Практично кажучи, статус == 0 для невдалого XmlHttpRequest слід вважати невизначеною помилкою.

Фактична специфікація W3C визначає умови, для яких тут повертається нуль: https://fetch.spec.whatwg.org/#concept-network-error

Як видно з специфікації (отримання або XmlHttpRequest), цей код може бути результатом помилки, яка сталася ще до того, як з сервером зверталися.

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

1. Незаконне перехресне походження (див. CORS )
2. Блок брандмауера або фільтрування
3. Сам запит скасовано в коді
4. Встановлене розширення браузера придушує речі

Що б корисно було б, щоб браузери надавали детальну звітність про помилки для більшості таких сценаріїв == 0. Дійсно, іноді статус == 0 супроводжує корисне консольне повідомлення, але в інших немає іншої інформації.

Що варто, залежно від браузера, дзвінки AJAX на основі jQuery зателефонують на ваш успішний зворотний виклик з кодом статусу HTTP 0. Ми знайшли код статусу "0", як правило, означає, що користувач переходить на іншу сторінку раніше виклик AJAX завершено.

Не той самий стек технологій, який ви використовуєте, але, сподіваємось, корисний для когось.

wininet.dll повертає як стандартні, так і нестандартні коди статусу, наведені нижче.

401 - Unauthorized file
403 - Forbidden file
404 - File Not Found
500 - some inclusion or functions may missed
200 - Completed

12002 - Server timeout
12029,12030, 12031 - dropped connections (either web server or DB server)
12152 - Connection closed by server.
13030 - StatusText properties are unavailable, and a query attempt throws an exception

Щодо коду статусу "нуль", ви намагаєтеся зробити запит на локальній веб-сторінці, що працює на веб-сервері або без веб-сервера?

XMLHttpRequest status = 0 і XMLHttpRequest statusText = невідомо можуть допомогти вам, якщо ви не запускаєте свій скрипт на веб-сервері.

Обхід: що ми в кінцевому підсумку робили

Ми подумали, що це стосується проблем із брандмауером, і тому ми придумали рішення, яке зробило трюк. Якщо у когось є те саме питання, ось що ми зробили:

1. Ми все ще записуємо дані в текстовий файл на локальний жорсткий диск, як це було раніше, використовуючи HTA.

2. Коли користувач натискає "повернути дані назад на сервер", HTA зчитує дані і виписує HTML-сторінку, яка включає ці дані як острів даних XML (фактично використовуючи скрипт SCRIPT LANGUAGE = XML-блок сценарію).

3. HTA запускає посилання на сторінку HTML у браузері.

4. Сторінка HTML тепер містить javascript, який розміщує дані на сервері (використовуючи Microsoft.XMLHTTP).

Сподіваюсь, це допоможе будь-кому із подібною вимогою. У цьому випадку це була Flash-гра, яка використовується на ноутбуці на tradeshows. У нас ніколи не було доступу до ноутбука, і ми могли лише надіслати його електронною поштою клієнтові, оскільки це торгове шоу відбувалося в іншій країні.

Код відповіді HTTP 0 означає, що запит AJAX скасовано.

Це може статися або від тайм-ауту, аборту XHR або з брандмауеру, який тупотить за запитом. Час очікування є загальним, це означає, що запит не вдалося виконати протягом визначеного часу. Аборт XHR зробити дуже просто ... ви можете фактично зателефонувати .abort () на об'єкт XMLHttpRequest, щоб скасувати виклик AJAX. ( Це хороша практика для однієї сторінки програми, якщо ви не хочете, щоб дзвінки AJAX поверталися та намагалися посилатись на об'єкти, які були знищені. ) Як зазначено у позначеній відповіді, брандмауер також міг би скасувати запит і запустити це 0 відповідей.

XHR Abort: Скасувати запити Ajax за допомогою jQuery

var xhr = $.ajax({
    type: "POST",
    url: "some.php",
    data: "name=John&location=Boston",
    success: function(msg){
       alert( "Data Saved: " + msg );
    }
});

//kill the request
xhr.abort()

Варто зазначити, що запуск методу .abort () на об'єкт XHR також призведе до запуску зворотного виклику помилок. Якщо ви робите будь-який вид обробки помилок, що аналізує ці об'єкти, ви швидко помітите, що перерваний XHR та час очікування XHR є однаковими, але при jQuery текстStatus, який передається зворотному виклику помилки, буде "перерваний", коли перервано і настає "тайм-аут" з таймаутом. Якщо ви використовуєте Zepto (дуже схожий на jQuery), тип помилки буде "помилкою", коли перервано, та "таймаутом", коли виникає таймаут.

jQuery: error(jqXHR, textStatus, errorThrown);
Zepto:  error(xhr, errorType, error);

Як детально описано у цій відповіді на цій сторінці , код статусу 0 означає, що запит чомусь не вдався, а бібліотека javascript інтерпретувала помилку як код статусу 0.

Щоб перевірити це, ви можете виконати одну з наступних дій:

1) Використовуйте це хромоване розширення. Запросите перенаправити URL-адресу з httpsверсії свого URL-адреси на httpверсію, оскільки це призведе до змішаної помилки безпеки вмісту і в кінцевому підсумку генерує код статусу 0. Перевагою такого підходу є те, що ви Вам не доведеться взагалі змінювати додаток, і ви можете просто "переписати" URL-адресу, використовуючи це розширення.

2) Змініть код своєї програми, щоб необов'язково зробити перенаправлення кінцевої точки на httpверсію URL-адреси замість httpsверсії (або навпаки). Якщо ви це зробите, запит не вдасться з кодом статусу 0.

У моєму випадку статус став 0, коли я забуду поставити WWW перед моїм доменом. Оскільки всі мої запити на Ajax були жорстко кодовані http: /WWW.mydomain.com, а завантажена веб-сторінка була б просто http://mydomain.com, це стало проблемою безпеки, оскільки це інший домен. Я в кінцевому підсумку робив переспрямування у своєму .htaccess-файлі, щоб завжди ставити www попереду.

У моєму випадку це було через те, що виклик AJAX був заблокований браузером через політику того самого походження . Це було найменш очікуваним, адже всі мої HTML та скрипти, з яких вони надходять 127.0.0.1. Як їх можна вважати різними походженнями?

У будь-якому разі, першопричиною була невинно виглядає <base>тег:

<base href='<%=request.getScheme()%>://<%=request.getServerName() + ":" + request.getServerPort() + request.getContextPath()%>/'/>

Я видалив <base>тег, який мені до речі не знадобився, і зараз він працює чудово!

Я знайшов нову і незадокументовану причину статусу == 0. Ось що у мене було:

XMLHttpRequest.status === 0
XMLHttpRequest.readyState === 0
XMLHttpRequest.responseText === ''
XMLHttpRequest.state() === 'rejected'

Він не був перехресним походженням, мережею або через скасовані запити (за кодом або за допомогою навігації користувача). Нічого в консолі розробника чи в мережевому журналі.

Я міг знайти дуже мало документації про state () (Mozilla не перераховує її, W3C робить), і жодна з них не згадувала "відхилено".

Виявляється, це був мій блокатор оголошень (uBlock Origin на Firefox).

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

function request(url) {
    var request = new XMLHttpRequest();
    try {
        request.open('GET', url, false);
        request.send(null);
    } catch (e) {
        console.log(url + ': ' + e);
    }
}

Наприклад :

NetworkError: сталася помилка в мережі.

У випадку, якщо хтось інший стикається з цією проблемою, це ставило мені проблеми через запит AJAX та звичайний запит форми. Я вирішив це наступним рядком:

<form onsubmit="submitfunc(); return false;">

Ключ є поверненням помилковим, через що форма не надсилається. Ви також можете просто повернути помилку зсередини submitfunc (), але я вважаю, що явно це написано, щоб було зрозуміліше.

Слід зазначити, що завантаження файлу ajax, що перевищує client_max_body_sizeдирективу для nginx, поверне цей код помилки.

Якщо ви тестуєте на локальному ПК, він не працюватиме. Для перевірки прикладу Ajax потрібно розмістити HTML-файли на веб-сервері.

У моєму випадку помилка сталася на сторінці, яка запитується за протоколом HTTP, і всередині неї Javascript намагається зробити запит HTTPS. І навпаки.

Після завантаження сторінки натисніть F12 (або Ctrl + U) і подивіться HTML-код вашої сторінки. Якщо ви бачите щось подібне у своєму коді:

<!-- javascript request inside the page -->
<script>
var ajaxurl = "https://example.com/wp-admin/admin-ajax.php";
(...)
</script>

І вашу сторінку запитували так:

http://example.com/example-page/2019/09/13/my-post/#elf_l1_Lw

Ви, безумовно, зіткнетеся з цією помилкою.

Щоб виправити це, встановіть протокол запиту Javascript рівний протоколу запиту сторінки.

Ця ситуація, що стосується різних протоколів, для запитів на сторінку та js, згадувалася раніше у відповіді Бреда Паркса, але, я думаю, діагностична методика, представлена ​​тут, легша для більшості користувачів.