Чи має значення статусу HTTP 0 значення?

Схоже, що коли ви робите XMLHttpRequest із сценарію в браузері, якщо браузер налаштований на роботу в автономному режимі або якщо мережевий кабель витягнутий, запит завершується помилкою і зі статусом = 0. 0 не входить до числа допустимих Коди стану HTTP.

Що означає код стану 0? Чи означає це одне і те ж у всіх браузерах та для всіх служб клієнтських служб HTTP? Це частина специфікації HTTP чи частина інших специфікацій протоколу? Здається, це означає, що запит HTTP взагалі не може бути зроблений, можливо, тому, що адресу сервера не вдалося вирішити.

Яке повідомлення про помилку доречно показати користувачеві? "Або ви не підключені до Інтернету, або веб-сайт стикається з проблемами, або в адресі може бути помилка друку"?

До цього слід додати, що я бачу поведінку у FireFox, коли встановлено на "Працювати в автономному режимі", але не в Microsoft Internet Explorer, коли встановлено на "Працювати в автономному режимі". В IE користувач отримує діалогове вікно, що дає можливість вийти в Інтернет. FireFox не повідомляє користувача перед тим, як повернути помилку.

Я прошу це у відповідь на запит "показати краще повідомлення про помилку". Те, що робить Internet Explorer - це добре. Він повідомляє користувачеві, що спричиняє проблему, і дає можливість виправити її. Для того, щоб отримати еквівалентний UX з FireFox, мені потрібно зробити висновок про причину проблеми та повідомити користувача. То що загалом я можу зробити з статусу 0? Це має універсальне значення або мені нічого не говорить?

Коротка відповідь

Це не код відповіді HTTP, але він задокументований WhatWG як дійсне значення для атрибута статусу відповіді XMLHttpRequestабо отримання.

Взагалі кажучи, це значення за замовчуванням, яке використовується, коли немає реального коду стану HTTP для повідомлення та / або сталася помилка під час надсилання запиту або отримання відповіді. Можливі сценарії, коли це так, включають, але не обмежуючись:

• Запит ще не надіслано або скасовано.
• Браузер все ще чекає отримання статусу відповіді та заголовків.
• Під час запиту зв’язок розірвано.
• Запит минув.
• Запит зіткнувся з нескінченним циклом переспрямування.
• Браузер знає стан відповіді, але ви не маєте доступу до нього через обмеження безпеки, пов’язані з Політикою того самого походження .

Довга відповідь

По-перше, повторюємо: 0 - це не код стану HTTP. У Розділі 6.1 RFC 7231 є їх повний перелік , який не включає 0, а вступ до розділу 6 чітко зазначає, що

Елементом коду стану є трицифровий цілочисельний код

що 0 не є.

Однак 0 як значення .statusатрибута об’єкта XMLHttpRequest задокументовано, хоча відстежити всі відповідні деталі дещо складно. Ми починаємо з https://xhr.spec.whatwg.org/#the-status-attribute , документуючи .statusатрибут, який просто говорить:

statusАтрибут повинен повернути відповідь «сек статусу .

Це може звучати марно і тавтологічно, але насправді тут є інформація! Пам'ятайте, що в цій документації йдеться про .responseатрибут відповіді XMLHttpRequest, а не відповіді, тому це говорить нам про те, що визначення статусу на об'єкті XHR відкладено на визначення статусу відповіді в специфікації "Вибрати".

Але який об'єкт відповіді? Що робити, якщо ми фактично ще не отримали відповідь? Вбудоване посилання на слово "відповідь" переводить нас на https://xhr.spec.whatwg.org/#response , де пояснюється:

Ан XMLHttpRequestмає відповідну відповідь. Якщо не вказано інше, це помилка мережі .

Отже, відповідь, статус якої ми отримуємо, за замовчуванням є помилкою мережі. І шукаючи всюди фразу "встановити відповідь на", яка використовується в специфікації XHR, ми можемо побачити, що вона встановлена ​​в п'яти місцях:

• До помилки мережі, коли:

  • open()метод викликається, або
  • Відгук у організмі «сек потоку є помилковим (див алгоритму , описаним в документації дляsend() методі )
  • встановлено прапор очікування, що спричиняє кроки помилки запиту запускаються
  • abort()метод викликається, в результаті чого дії помилок запиту для запуску

• На відповідь, отриману шляхом надсилання запиту за допомогою Fetch, або за допомогою завдання відповіді процесу Fetch (якщо запит XHR є асинхронним), або завдання кінцевого завдання відповіді процесу Fetch (якщо запит XHR синхронний).

Розглядаючи стандарт Fetch , ми можемо побачити, що:

Помилка мережі - це відповідь , статус якої завжди0

тому ми можемо негайно сказати, що ми побачимо статус 0 на об'єкті XHR у будь-якому з випадків, коли специфікація XHR говорить, що відповідь повинна бути встановлена ​​на помилку мережі. (Цікаво, що сюди входить випадок, коли потік тіла "помиляється", що, як стверджує специфікація Fetch, може статися під час розбору тіла після отримання статусу - тому теоретично я вважаю, що об'єкт XHR може мати свій статус встановіть на 200, потім під час отримання тіла зіткнетеся з помилкою, що не вистачає пам’яті, і тому змініть його статус на 0.)

Ми також зазначаємо у стандарті Fetch, що існує кілька інших типів відповідей, статус яких визначено рівним 0, існування яких пов'язане із запитами про перехресне походження та політикою того самого походження:

Непрозора відфільтрована відповідь - це відфільтрована відповідь, чий ... статус0 ...

Відфільтрована відповідь непрозорого перенаправлення - це відфільтрована відповідь , статус якої 0...

(різні інші подробиці щодо цих двох типів відповідей опущено).

Але крім них, є також багато випадків, коли алгоритм Fetch (а не специфікація XHR, яку ми вже розглядали) вимагає від браузера повернути мережеву помилку! Дійсно, фраза "повернути помилку мережі" з'являється 40 разів у стандарті Fetch. Я не буду намагатись перерахувати всі 40 тут, але зазначу, що вони включають:

• Випадок, коли схема запиту не розпізнана (наприклад, спроба надіслати запит на madeupscheme: //foobar.com)
• Дивовижно невиразна інструкція "Якщо ви сумніваєтесь, поверніть помилку мережі". в алгоритмах обробки ftp: // та file: // URL-адрес
• Нескінченні переспрямування: "Якщо кількість запитів переспрямовує двадцять, поверніть мережеву помилку."
• Куча проблем, пов’язаних з CORS, наприклад, "Якщо забруднення відповідей httpRequest не є" cors ", а перевірка політики ресурсів перехресного джерела із заблокованими поверненнями запитів та відповідей повертає помилку мережі".
• Помилки підключення: "Якщо з’єднання не вдалося, поверніть помилку мережі."

Іншими словами: кожен раз, коли щось піде не так, інше , ніж отримати реальний HTTP код статусу помилки на кшталт 500 або 400 з сервера, ви в кінцевому підсумку з атрибутом стану 0 на вашому об'єкті XHR або Fetch об'єкт відповіді в браузері. Кількість можливих конкретних причин, перелічених у специфікації, величезна.

Нарешті: якщо вас чомусь цікавить історія специфікації, зверніть увагу, що ця відповідь була повністю переписана в 2020 році, і що вас може зацікавити попередня редакція цієї відповіді , яка проаналізувала, по суті, ті самі висновки. старіші (і набагато простіші) специфікації W3 для XHR, перш ніж вони були замінені на більш сучасні та більш складні специфікації WhatWG, на які посилається ця відповідь.

статус 0 з’являється, коли дзвінок ajax було скасовано до отримання відповіді, оновивши сторінку або запитувавши недоступну URL-адресу.

цей статус не задокументовано, але існує через ajax та makeRequest-дзвінки з gadget.io.

з документації http://www.w3.org/TR/XMLHttpRequest/#the-status-attribute означає, що запит було скасовано перед тим, як іти куди-небудь

Знайте, це старий пост. Але ці питання все ще існують.

Ось деякі мої висновки з цього приводу, що були докладно пояснені.

"Статус" 0 означає одну з 3 речей відповідно до специфікації XMLHttpRequest:

• dns розпізнавання імені не вдалося (це, наприклад, коли мережевий штекер витягнутий)

• сервер не відповів (він недоступний або не відповідає)

• запит було скасовано через проблему CORS (аборт виконується користувальницьким агентом і слідує за невдалим варіантом попереднього польоту).

Якщо ви хочете піти далі, зануртесь глибоко в суть XMLHttpRequest. Я пропоную прочитати послідовність оновлення у готовому стані ([0,1,2,3,4] - звичайна послідовність, [0,1,4] відповідає статусу 0, [0,1,2,4] означає відсутність вмісту що може бути помилкою чи ні). Ви також можете підключити слухачів до xhr (onreadystatechange, onabort, onerror, ontimeout), щоб з'ясувати деталі.

З специфікації ( XHR Living spec ):

const unsigned short UNSENT = 0;
const unsigned short OPENED = 1;
const unsigned short HEADERS_RECEIVED = 2;
const unsigned short LOADING = 3;
const unsigned short DONE = 4;

Починаючи з iOS 9, вам потрібно додати "Налаштування безпеки транспорту додатків" у файл info.plist і дозволити параметр "Дозволити довільні завантаження" перед тим, як робити запит на незахищену веб-службу HTTP. У мене виникла ця проблема в одному з моїх додатків.

Так, дещо, як дзвінок ajax перервався. Причина може бути наступною.

1. Перед завершенням запиту ajax користувач перейшов на іншу сторінку.
2. Запит Ajax має час очікування.
3. Сервер не може повернути жодної відповіді.