Список кодів стану HTTP

Код стану HTTP ( англ. HTTP status code ) - Частина першого рядка відповіді сервера при запитах за протоколом HTTP. Він являє собою ціле число із трьох арабських цифр [1]. Перша цифра вказує на клас стану. За кодом відповіді зазвичай слід відокремлена пробілом пояснююча фраза англійською мовою, яка роз'яснює людині причину саме такої відповіді. Приклади:

  • 201 Webpage Created.
  • 403 Access allowed only for registered users.
  • 507 Insufficient Storage.

Клієнт дізнається за кодом відповіді про результати його запиту і визначає які дії йому робити далі. Набір кодів стану є стандартом, і вони описані у відповідних документах RFC. Введення нових кодів повинне проводитися тільки після погодження з IETF. Тим не менш, відомо про двох використовуваних кодах, не згаданих у RFC: 449 Retry With. Так само згадується пояснювальна фраза "Reply With" [2] в специфікації по WebDAV в Microsoft Developer Network, введений Microsoft і 509 Bandwidth Limit Exceeded, введений в cPanel. Компанія Google запропонувала комітету IETF використовувати HTTP-код 451 для повідомлення про навмисне блокування порталів [3].

Клієнт може не знати всі коди стану, але він зобов'язаний відреагувати відповідно до класу коду. В даний час виділено п'ять класів кодів стану.

Веб-сервер Internet Information Services у своїх файлах журналів крім стандартних кодів стану використовує підкоди, записуючи їх через точку після основного. При цьому у відповідях від сервера даний підкодів не розміщується - він потрібний адміністратору сервера щоб той міг більш точно визначати джерела проблем.


1. Оглядовий список

Нижче представлений перелік усіх описаних в даній статті кодів відповіді:

Діаграма прийняття веб-сервером рішень на основі заголовків
Статистика за кодами відповіді, що згенерувала аналізатором логів Webalizer
Статистика по помилках HTTP, що згенерувала лог-аналізатором AWStats

2. Опис кодів

2.1. Інформаційні

У цей клас виділені коди, що інформують про процес передачі. При роботі через протокол версії 1.0 повідомлення з такими кодами повинні ігноруватися. У версії 1.1 клієнт повинен бути готовий прийняти цей клас повідомлень як звичайна відповідь, але сервера відправляти небудь не потрібно. Самі повідомлення від сервера містять тільки стартову рядок відповіді і, якщо потрібно, декілька специфічних для відповіді полів заголовка. Проксі-сервера подібні повідомлення повинні відправляти далі від сервера до клієнта.

  • 100 Continue - сервер задоволений початковими відомостями про запит, клієнт може продовжувати пересилати заголовки. З'явився в HTTP/1.1.
  • 101 Switching Protocols - сервер пропонує перейти на більш відповідний для зазначеного ресурсу протокол; список пропонованих протоколів сервер обов'язково вказує в поле заголовка Update. Якщо клієнта це зацікавить, то він посилає новий запит із зазначенням іншого протоколу. З'явився в HTTP/1.1.
  • 102 Processing - запит прийнято, але на його обробку знадобиться тривалий час. Використовується сервером, щоб клієнт не розірвав з'єднання через перевищення часу очікування. Клієнт при отриманні такої відповіді повинен скинути таймер і чекати наступної команди в звичайному режимі. З'явився в WebDAV.

2.2. Успіх

Повідомлення даного класу інформують про випадки успішного приймання та обробки запиту клієнта. В залежності від статусу сервер може ще передати заголовки і тіло повідомлення.

  • 200 OK - успішний запит. Якщо клієнтом були запитані небудь дані, то вони знаходяться в заголовку і / або тілі повідомлення. З'явився в HTTP/1.0.
  • 201 Created - в результаті успішного виконання запиту був створений новий ресурс. Сервер повинен вказати його місце розташування в заголовку Location. Сервера рекомендується ще вказувати в заголовку характеристики створеного ресурсу (наприклад, в полі Content-Type). Якщо сервер не впевнений, що ресурс дійсно буде існувати до моменту отримання даного повідомлення клієнтом, то краще використовувати відповідь з кодом 202. З'явився в HTTP/1.0.
  • 202 Accepted - запит був прийнятий на обробку, але вона не завершена. Клієнту не обов'язково чекати остаточної передачі повідомлення, так як може бути початий дуже довгий процес. З'явився в HTTP/1.0.
  • 203 Non-Authoritative Information - аналогічно відповіді 200, але в цьому випадку передана інформація була взята не з первинного джерела (резервної копії, іншого сервера і т. д.) і тому може бути неактуальною. З'явився в HTTP/1.1.
  • 204 No Content - сервер успішно обробив запит, але у відповіді були передані тільки заголовки без тіла повідомлення. Клієнт не повинен оновлювати вміст документа, але може застосувати до нього отримані метадані. З'явився в HTTP/1.0.
  • 205 Reset Content - сервер зобов'язує клієнта скинути введені користувачем дані. Тіла повідомлення сервер при цьому не передає і документ оновлювати не обов'язково. З'явився в HTTP/1.1.
  • 206 Partial Content - сервер вдало виконав частковий GET-запит, повернувши тільки частину повідомлення. У заголовку Content-Range сервер вказує байтові діапазони вмісту. Особливу увагу при роботі з такими відповідями слід приділити кешуванню. З'явився в HTTP/1.1. ( детальніше ...)
  • 207 Multi-Status - сервер передає результати виконання відразу декількох незалежних операцій. Вони поміщаються в саме тіло повідомлення у вигляді XML -документа з об'єктом multistatus. Не рекомендується розміщувати в цьому об'єкті статуси з серії 1xx через безглуздість і надмірності. З'явився в WebDAV.
  • 226 IM Used - заголовок A-IM від клієнта був успішно прийнятий і сервер повертає вміст з урахуванням зазначених параметрів. Введено в RFC 3229 для доповнення протоколу HTTP підтримкою дельта-кодування.

2.3. Перенаправлення

Коди цього класу повідомляють клієнту, що для успішного виконання операції необхідно зробити інший запит, як правило, по іншому URI. З даного класу п'ять кодів 301, 302, 303, 305 і 307 відносяться безпосередньо до перенапрямкам. Адреса, за якою клієнтові слід провести запит, сервер вказує в заголовку Location. При цьому допускається використання фрагментів в цільовому URI.

За останніми стандартами клієнт може виробляти перенаправлення без запиту користувача тільки якщо другий ресурс буде запитуватися методом GET GET або HEAD HEAD [7]. У попередніх специфікаціях говорилося, що для уникнення кругових переходів користувача слід запитувати після 5-го поспіль перенаправлення [12]. При всіх перенаправлення, якщо метод запиту був не HEAD, то в тіло відповіді слід включити короткий гіпертекстове повідомлення з цільовим адресою, щоб у разі помилки користувач зміг сам зробити перехід.

Розробники HTTP відзначають, що багато клієнтів при перенаправлення з кодами 301 і 302 помилково застосовують метод GET до другого ресурсу, незважаючи на те, що до першого запит був з іншим методом (найчастіше PUT) [13]. Щоб уникнути непорозумінь, у версії HTTP/1.1 були введені коди 303 і 307 і їх рекомендовано використовувати замість 302. Змінювати метод потрібно тільки якщо сервер відповів 303. В інших випадках наступний запит виробляти з вихідним методом.

Поведінка клієнтів при різних Перенаправлення описано в таблиці:

Статус відповіді Кешування Якщо метод не GET або HEAD
301 Moved Permanently Можна як зазвичай. Запитати в користувача підтвердження і запросити інший ресурс вихідним методом.
307 Temporary Redirect Можна тільки якщо вказаний заголовок Cache-Control або Expires.
302 Found (HTTP/1.1)
302 Moved Temporarily (HTTP/1.0)
303 See Other Не можна. Перейти автоматично, але вже методом GET.
  • 300 Multiple Choices - за вказаною URI існує кілька варіантів надання ресурсу за типом MIME, по мові чи по іншим характеристикам. Сервер передає з повідомленням список альтернатив, даючи можливість зробити вибір клієнтові автоматично або користувачеві. З'явився в HTTP/1.0.
  • 301 Moved Permanently - запитаний документ був остаточно перенесено на новий URI, зазначений у полі Location заголовка. Деякі клієнти некоректно поводяться при обробці даного коду. З'явився в HTTP/1.0.
  • 302 Found, 302 Moved Temporarily - запитаний документ тимчасово доступний по іншому URI, вказаний у заголовку в поле Location. Цей код може бути використаний, наприклад, при керованому сервером узгодженні вмісту. Деякі клієнти некоректно поводяться при обробці даного коду. Введено в HTTP/1.0.
  • 303 See Other - документ по запрошенням URI потрібно запросити за адресою в полі Location заголовка з використанням методу GET незважаючи навіть на те, що перший запитували іншим методом. Цей код був введений разом з 307 -им для уникнення неоднозначності, щоб сервер був упевнений, що наступний ресурс буде запитаний методом GET. Наприклад, на веб-сторінці є поле введення тексту для швидкого переходу та пошуку. Після введення даних браузер робить запит методом POST, включаючи в тіло повідомлення введений текст. Якщо виявлений документ із введенням назвою, то сервер відповідає кодом 303, вказавши в заголовку Location його постійна адреса. Тоді браузер гарантовано його запросить методом GET для отримання вмісту. У противному випадку сервер просто поверне клієнтові сторінку з результатами пошуку. Введено в HTTP/1.1.
  • 304 Not Modified - сервер повертає такий код, якщо клієнт запросив документ методом GET, використовував заголовок If-Modified-Since або If-None-Match і документ не змінився з вказаного моменту. При цьому повідомлення сервера не повинно містити тіла. З'явився в HTTP/1.0.
  • 305 Use Proxy - запит до запитуваного ресурсу повинен здійснюватися через проксі-сервер, URI якого вказана в полі Location заголовка. Даний код відповіді можуть використовувати тільки вихідні HTTP-сервера (не проксі). Введено в HTTP/1.1.
  • 306 (зарезервовано) - використовувався раніше код відповіді, зараз зарезервований. Згаданий в RFC 2616 (оновлення HTTP/1.1).
  • 307 Temporary Redirect - запитаний ресурс на короткий час доступний по іншому URI, зазначений у полі Location заголовка. Цей код був введений разом з 303 замість 302-го для уникнення неоднозначності. Введено в RFC 2616 (оновлення HTTP/1.1).

2.4. Помилка клієнта

Клас кодів 4xx призначений для вказівки помилок з боку клієнта. При використанні всіх методів, крім HEAD, сервер повинен повернути в тілі повідомлення гіпертекстове пояснення для користувача.

  • 400 Bad Request - сервер виявив в запиті клієнта синтаксичну помилку. З'явився в HTTP/1.0.
  • 401 Unauthorized - запит вимагає ідентифікації користувача. Сервер повинен запитати ім'я і пароль у користувача, а той передасть їх у заголовку WWW-Authenticate в наступному запиті. Якщо були вказані невірні дані, то сервер знову поверне цей же статус. З'явився в HTTP/1.0.
  • 402 Payment Required - передбачається використовувати в майбутньому. На даний момент не використовується. Цей код передбачений для платних користувача сервісів, а не для хостингових компаній. Мається на увазі, що ця помилка не буде видана хостингових провайдером у разі простроченої оплати його послуг. Зарезервований, починаючи з HTTP/1.1.
Сервер повернув помилку 403 при спробі перегляду директорії "cgi-bin", доступ до якої був заборонений.
  • 403 Forbidden - сервер зрозумів запит, але він відмовляється його виконувати через обмеження в доступі для клієнта до зазначеного ресурсу. Якщо для доступу до ресурсу вимагається аутентифікація засобами HTTP, то сервер поверне відповідь 401 або 407 при використанні проксі. В іншому випадку обмеження були задані адміністратором сервера або розробником веб-додатки та можуть бути будь-якими в залежності від можливостей використовуваного програмного забезпечення. У будь-якому випадку клієнтові слід повідомити причини відмови в обробці запиту. Найбільш вірогідними причинами обмеження може послужити спроба доступу до системних ресурсів веб-сервера (наприклад, файлів .htaccess .htaccess або .htpasswd .htpasswd) або до файлів, доступ до яких був закритий за допомогою конфігураційних файлів, вимога аутентифікації не засобами HTTP, наприклад, для доступу до системі керування вмістом або розділу для зареєстрованих користувачів або сервер не задоволений IP-адресою клієнта, наприклад, при блокуваннях. З'явився в HTTP/1.0.
  • 404 Not Found - найпоширеніша помилка при користуванні Інтернетом, основна причина - помилка в написанні адреси Web-сторінки. Сервер зрозумів запит, але не знайшов відповідного ресурсу за вказаною URI. Якщо серверу відомо, що за цією адресою був документ, то йому бажано використовувати код 410. Відповідь 404 може використовуватися замість 403, якщо потрібно ретельно приховати від сторонніх очей певні ресурси. З'явився в HTTP/1.0.
  • 405 Method Not Allowed - зазначений клієнтом метод не можна застосувати до поточного ресурсу. У відповіді сервер повинен вказати доступні методи в заголовку Allow, розділивши їх комами. Цю помилку сервер повинен повертати, якщо метод йому відомий, але він не застосовний саме до вказаного в запиті ресурсу, якщо ж зазначений метод не застосовний на всіх сервері, то клієнту потрібно повернути код 501. З'явився в HTTP/1.1.
  • 406 Not Acceptable - запитаний URI не може задовольнити переданим в заголовку характеристикам. Якщо метод був не HEAD, то сервер повинен повернути список допустимих характеристик для даного ресурсу. З'явився в HTTP/1.1.
  • 407 Proxy Authentication Required - відповідь аналогічний коду 401 за винятком того, що аутентифікація проводиться для проксі-сервера. Механізм аналогічний ідентифікації на вихідному сервері. З'явився в HTTP/1.1.
  • 408 Request Timeout - час очікування сервером передачі від клієнта минув. Клієнт може повторити аналогічний попередньому запит в будь-який час. Наприклад, така ситуація може виникнути при завантаженні на сервер об'ємного файлу методом POST або PUT. У якийсь момент передачі джерело даних перестав відповідати, наприклад, через пошкодження компакт-диска або втрата зв'язку з іншим комп'ютером в локальній мережі. Поки клієнт нічого не передає, чекаючи від нього відповіді, з'єднання з сервером тримається. Через деякий час сервер може закрити з'єднання зі свого боку, щоб дати можливість іншим клієнтам зробити запит. Ця відповідь не повертається, коли клієнт примусово зупинив передачу по команді користувача або з'єднання перервалося з якихось інших причин, так як відповідь вже послати неможливо. З'явився в HTTP/1.1.
  • 409 Conflict - запит не може бути виконаний через конфліктного поводження до ресурсу. Таке можливо, наприклад, коли два клієнти намагаються змінити ресурс за допомогою методу PUT. З'явився в HTTP/1.1.
  • 410 Gone - таку відповідь сервер посилає, якщо ресурс раніше був за вказаною URL, але був вилучений і тепер недоступний. Сервера в цьому випадку невідомо і місце розташування альтернативного документа, наприклад, копії). Якщо у сервера є підозра, що документ найближчим часом може бути поновлений, то краще клієнтові передати код 404. З'явився в HTTP/1.1.
  • 411 Length Required - для зазначеного ресурсу клієнт повинен вказати Content-Length в заголовку запиту. Без вказівки цього поля не варто робити повторну спробу запиту до сервера з даного URI. Така відповідь природний для запитів типу POST і PUT. Наприклад, якщо за вказаною URI проводиться завантаження файлів, а на сервері стоїть обмеження на їх обсяг. Тоді розумніше буде перевірити на самому початку заголовок Content-Length і відразу відмовити у завантаженні, ніж провокувати безглузду навантаження, розриваючи з'єднання, коли клієнт дійсно пришле занадто об'ємне повідомлення. З'явився в HTTP/1.1.
  • 412 Precondition Failed - повертається, якщо жодне з умовних полів заголовка [ невідомий термін ] запиту не було виконано. З'явився в HTTP/1.1.
  • 413 Request Entity Too Large - повертається у випадку, якщо сервер відмовляється обробити запит через занадто великого розміру тіла запиту. Сервер може закрити з'єднання, щоб припинити подальшу передачу запиту. Якщо проблема тимчасова, то рекомендується у відповідь сервера включити заголовок Retry-After із зазначенням часу, після закінчення якого можна повторити аналогічний запит. З'явився в HTTP/1.1.
  • 414 Request-URL Too Long - сервер не може обробити запит через занадто довгого зазначеного URL. Таку помилку можна спровокувати, наприклад, коли клієнт намагається передати довгі параметри через метод GET, а не POST. З'явився в HTTP/1.1.
  • 415 Unsupported Media Type - з якихось причин сервер відмовляється працювати з вказаним типом даних при даному методі. З'явився в HTTP/1.1.
  • 416 Requested Range Not Satisfiable - в полі Range заголовка запиту був вказаний діапазон за межами ресурсу і відсутня поле If-Range. Якщо клієнт передав байтовий діапазон, то сервер може повернути реальний розмір у полі Content-Range заголовка. Даний відповідь не слід використовувати при передачі типу multipart/byteranges [Джерело не вказано 269 днів] . Введено в RFC 2616 (оновлення HTTP/1.1).
  • 417 Expectation Failed - з якихось причин сервер не може задовольнити значенню поля Expect заголовка запиту. Введено в RFC 2616 (оновлення HTTP/1.1).
  • 422 Unprocessable Entity - сервер успішно прийняв запит, може працювати із зазначеним видом даних, в тілі запиту XML -документ має вірний синтаксис, але є якась логічна помилка, через яку неможливо зробити операцію над ресурсом. Введено в WebDAV.
  • 423 Locked - цільовий ресурс із запиту заблокований від застосування до нього зазначеного методу. Введено в WebDAV.
  • 424 Failed Dependency - реалізація поточного запиту може залежати від успішності виконання іншої операції. Якщо вона не виконана і через це не можна виконати поточний запит, то сервер поверне цей код. Введено в WebDAV.
  • 425 Unordered Collection - надсилається, якщо клієнт надіслав запит, позначивши положення в невідсортоване колекції або використовуючи порядок проходження елементів, відмінний від серверного [Уточнити]. Введено в чернетці по WebDAV Advanced Collections Protocol [14].
  • 426 Upgrade Required - сервер вказує клієнтові на необхідність оновити протокол. Тема відповіді повинен містити правильно сформовані поля Upgrade і Connection. Введено в RFC 2817 для можливості переходу до TLS допомогою HTTP.
  • 449 Retry With - повертається сервером, якщо для обробки запиту від клієнта надійшло недостатньо інформації. При цьому в заголовок відповіді поміщається поле Ms-Echo-Request. Введено корпорацією Microsoft для WebDAV. На даний момент як мінімум використовується програмою Microsoft Money.
  • 456 Unrecoverable Error - повертається сервером, якщо обробка запиту викликає некорректіруемие збої в таблицях баз даних [Джерело не вказано 269 днів] . Введено корпорацією Microsoft для WebDAV.

2.5. Помилка сервера

Коди 5xx виділені під випадки невдалого виконання операції з вини сервера. Для всіх ситуацій, крім використання методу HEAD, сервер повинен включати в тіло повідомлення пояснення, яке клієнт відобразить користувачеві.

  • 500 Internal Server Error - будь-яка внутрішня помилка сервера, яка не входить в рамки інших помилок класу. З'явився в HTTP/1.0.
  • 501 Not Implemented - сервер не підтримує можливостей, необхідних для обробки запиту. Типова відповідь для випадків, коли сервер не розуміє зазначений у запиті метод. Якщо ж метод сервера відомий, але він не застосовний до даного ресурсу, то потрібно повернути відповідь 405. З'явився в HTTP/1.0.
  • 502 Bad Gateway - сервер в ролі шлюзу або проксі-сервера отримав повідомлення про невдалий виконанні проміжної операції. З'явився в HTTP/1.0.
  • 503 Service Unavailable - сервер тимчасово не має можливості обробляти запити з технічних причин (обслуговування, перевантаження та інше). У полі Retry-After заголовка сервер може вказати час, через який клієнтові рекомендується повторити запит. Хоча під час перевантаження очевидним здається відразу розривати з'єднання, ефективніше може виявитися установка великого значення поля Retry-After для зменшення частоти надлишкових запитів. З'явився в HTTP/1.0.
  • 504 Gateway Timeout - сервер в ролі шлюзу або проксі-сервера не дочекався відповіді від вищестоящого сервера для завершення поточного запиту. З'явився в HTTP/1.1.
  • 505 HTTP Version Not Supported - сервер не підтримує або відмовляється підтримувати зазначену в запиті версію протоколу HTTP. З'явився в HTTP/1.1.
  • 506 Variant Also Negotiates - в результаті помилкової конфігурації обраний варіант вказує сам на себе, через що процес зв'язування переривається. Експериментальне. Введено в RFC 2295 для доповнення протоколу HTTP технологією Transparent Content Negotiation.
  • 507 Insufficient Storage - не вистачає місця для виконання поточного запиту. Проблема може бути тимчасовою. Введено в WebDAV.
  • 509 Bandwidth Limit Exceeded - використовується при перевищенні веб-майданчиком відведеного їй обмеження на споживання трафіка. В даному випадку власнику площадки слід звернутися до свого хостинг-провайдера. На даний момент цей код не описаний у одному RFC і використовується тільки модулем "bw / limited", що входить в панель управління хостингом cPanel, де і був введений.
  • 510 Not Extended - на сервері відсутній розширення, яка бажає використовувати клієнт. Сервер може додатково передати інформацію про доступні йому розширеннях. Введено в RFC 2774 для доповнення протоколу HTTP підтримкою розширень.

Примітки

  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 " 6.1.1 Status Code and Reason Phrase - tools.ietf.org/html/rfclink42 "в RFC 2068
  2. 1 2 2.2.6 449 "Retry With Status Code" / / Web Distributed Authoring and Versioning (WebDAV) Protocol: Client Extensions. - msdn.microsoft.com/en-us/library/dd891478 (PROT.10). aspx на сайті MSDN
  3. http://www.securitylab.ru/news/425708.php - www.securitylab.ru/news/link132 "Google запропонувала виділяти примусово заблоковані портали" / / SecurityLab.ru
  4. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 RFC 2616 - tools.ietf.org/html/rfc2616 # section-10.3
  5. 1 2 3 IETF Draft WebDAV Advanced Collections Protocol - S.4.2.5 - tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04 # section-4.2.5
  6. IETF Draft WebDAV Advanced Collections Protocol - S.10 - tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04 # section-9.13
  7. 1 2 3 4 5 6 7 8 9 10 RFC 2616 "10.3 Redirection 3xx" (стор. 61) - tools.ietf.org/html/rfc2616 # section-10.3
  8. IETF Draft WebDAV Advanced Collections Protocol - S.4.3.1.1 - tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04 # section-4.3.1
  9. IETF Draft WebDAV Advanced Collections Protocol - S.5.3.2 - tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04 # section-5.3.2
  10. RFC 2295 Transparent Content Negotiation in HTTP - S.8.1 - tools.ietf.org/html/rfc2295 # section-8.1
  11. IETF Draft WebDAV Advanced Collections Protocol - S.7.1 - tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04 # section-7.1
  12. RFC 2068 "10.3 Redirection 3xx" (стор. 56) - tools.ietf.org/html/rfclink42.
  13. RFC 2616, розділ "10.3.3 302 Found", сторінка 63 - tools.ietf.org/html/rfc2616 # page-63.
  14. WebDAV Advanced Collections Protocol S.5.3.2 - tools.ietf.org/html/draft-ietf-webdav-collection-protocol-04 # section-5.3.2