| HTTP статус-код |
Значення статус-коду |
| 100 |
Клієнт має продовжити надсилати запит. Ця тимчасова відповідь використовується для сповіщення клієнта про те, що його частковий запит був прийнятий сервером і ще не був відхилений. Клієнт має продовжити надсилати решту запиту, або, якщо запит уже завершений, ігнорувати цю відповідь. Сервер повинен надіслати остаточну відповідь клієнту після завершення запиту. |
| 101 |
Сервер зрозумів запит клієнта і сповістить його через заголовок Upgrade, щоб прийняти інший протокол для виконання цього запиту. Після відправлення цього останнього порожнього рядка, сервер перейде на ті протоколи, що визначені в заголовку Upgrade. Лише тоді, коли перехід на новий протокол буде вигіднішим, слід застосовувати подібні заходи. Наприклад, перехід на нову версію HTTP може бути допоміжним у порівнянні зі старими, або перейти на протокол з реальним часом та синхронним режимом для передачі ресурсів, що використовують такі характеристики. |
| 102 |
Розширений статус-код WebDAV (RFC 2518), що представляє продовження обробки. |
| 200 |
Запит успішно виконано, заголовки або тіло даних, що очікуються в запиті, будуть повернені з цією відповіддю. |
| 201 |
Запит реалізовано, і новий ресурс було створено відповідно до запиту, його URI було повернуто з заголовком Location. Якщо потрібний ресурс не може бути створений оперативно, слід повернути '202 Accepted'. |
| 202 |
Сервер прийняв запит, але обробка ще не завершена. Як може бути відхилено, в кінцевому підсумку цей запит може, або не може бути реалізовано. У випадку асинхронних операцій нічого більш зручного, ніж відправлення цього статус-коду, не може бути. Мета відповіді з поверненням статус-коду 202 - дозволити серверу приймати запити для інших процесів (наприклад, для обробки запитів кожного дня один раз), не змушуючи клієнта підтримувати з’єднання з сервером, поки обробка не завершена. Коли запит оброблюється і повертається 202 статус-код, він повинен містити в повернутому контенті деяку інформацію, щоб вказати на поточний стан обробки, а також посилання на моніторинг стану або прогнозування стану, щоб користувач міг оцінити, чи операція завершена. |
| 203 |
Сервер успішно обробив запит, але метаінформація отриманого заголовка не є дійсною колекцією оригінального сервера, а є копією з локального або третьої сторони. Поточна інформація може бути підмножиною або надмножиною оригінальної версії. Наприклад, метадані ресурсу можуть призвести до знання оригінальним сервером. Використання цього статус-коду не є обов'язковим і доречне лише в тому випадку, якщо відповідь, яка не використовує цей статус-код, поверне 200 OK. |
| 204 |
Сервер успішно обробив запит, але не потрібно повертати жодного контенту повноти, і він хоче повернути оновлену метаінформацію. Відповідь може містити нову або оновлену метаінформацію у вигляді заголовків. Якщо ці заголовки існують, то вони повинні відповідати запитуваним змінним. Якщо клієнт - це браузер, то браузер повинен залишити відкритою ту сторінку, з якої було надіслано запит, без змін у документальному вигляді, незважаючи на те, що нова або оновлена метаінформація має бути застосована до активного перегляду у документі браузера. Оскільки 204 відповідь забороняє включати будь-яке тіло повідомлення, вона завжди закінчується на першому порожньому рядку після заголовків відповідей. |
| 205 |
Сервер успішно обробив запит, але жодного контенту не повернув. Однак, на відміну від 204 відповіді, відповідь з цією статус-кодом вимагає, щоб запитувач скинув перегляд документа. Ця відповідь зазвичай використовується для скидання форм безпосередньо після того, як користувач ввів дані, щоб полегшити їм можливість розпочати новий ввід. Як і в 204 відповіді, ця відповідь також забороняє включати будь-яке тіло повідомлення, і закінчується на першому порожньому рядку після заголовків. |
| 206 |
Сервер успішно обробив частину запиту GET. Подібно до HTTP-інструментів для завантаження, таких як FlashGet або Thunder, цей тип відповіді застосовується для поновлення завантаження або розбивки великого документу на кілька сегментів для одночасного завантаження. Цей запит повинен містити заголовок Range, щоб зазначити, який діапазон контенту бажає отримати клієнт, і може містити If-Range як умову для запиту. Відповідь повинна містити такі заголовкові поля: Content-Range, щоб вказати діапазон контенту, що повертається в цій відповіді; якщо Content-Type є multipart/byteranges, кожен багаточастинний сегмент повинен містити заголовок Content-Range для вказівки діапазону контенту цього сегмента. Якщо в запиті присутній Content-Length, його значення повинно відповідати реальному байтовому числу діапазону контенту, що повертається. Залежності ETag і/або Content-Location, якщо той же запит повинен був повернути відповідь 200. Expires, Cache-Control і/або Vary, якщо їх значення можуть відрізнятися від значень у інших відповідях. Якщо цей запит використовував If-Range для сильної перевірки кешу, ця відповідь не повинна містити інших заголовків контенту; якщо запит використовував If-Range для слабкої перевірки кешу, ця відповідь забороняє включення інших заголовків контенту, щоб уникнути несоответствий між кешованим контентом і новими заголовками метаінформації. В іншому разі ця відповідь повинна включати всі заголовкові поля, які повинні були бути повернуті в відповіді 200. Якщо заголовки ETag або Last-Modified не можуть точно відповідати, кеш клієнта забороняє поєднувати контент, повернутий у відповіді 206 з будь-яким попередньо кешованим контентом. Будь-який кеш, що не підтримує заголовки Range і Content-Range, забороняється кешувати зміст, повернутий у відповіді 206. |
| 207 |
Розширений статус-код WebDAV (RFC 2518), представляє, що подальше тіло повідомлення буде XML-повідомленням і може містити набір окремих кодів відповідей, залежно від кількості підзапитів, що були раніше надіслані. |
| 300 |
Запитане ресурс має кілька доступних зворотних відгуків, кожен зі своїм адресою та повідомленням, керованим браузером. Користувач або браузер можуть вибрати один з переважних адрес для перенаправлення. Якщо це не запит HEAD, ця відповідь повинна включати тіло, що містить список характеристик та адрес ресурсів, з яких користувач або браузер може вибрати найбільш відповідну адресу перенаправлення. Формат цього тіла визначається форматом, описаним заголовком Content-Type. Браузер може робити вибір автоматично, ґрунтуючись на формі відповіді та своїй здатності. Однак, RFC 2616 стандарт не вказує, як має проводитися таке автоматичне вибирання. Якщо сервер має переважаюче зворотне вибрання, то URI цього зворотного вибору слід вказати в заголовку локалізації; браузер може використовувати це значення як автоматичну адресу перенаправлення. До того ж, ця відповідь в нормальних випадках також може бути кешованою. |
| 301 |
Запитаний ресурс постійно переміщено в нове місце, і в майбутньому всі посилання на цей ресурс слід використовувати один з URI, що повертаються цією відповіддю. Якщо можливо, клієнти, які мають функцію редагування посилань, повинні автоматично змінювати запитувану адресу на адресу, повернену сервером. Якщо не зазначено інакше, ця відповідь також може бути кешованою. Нові постійні URI повинні бути повернені у заголовку Location. Якщо це не запит HEAD, то тіло відповіді повинно містити гіперпосилання на новий URI, а також короткий опис. Якщо це не є запитом GET або HEAD, переказ браузера автоматично забороняється, якщо не отримано підтвердження користувача, оскільки умови запиту можуть бути змінені в процесі. Зверніть увагу: для деяких браузерів, які використовують протокол HTTP/1.0, коли POST запит отримав 301 відповідь, наступний запит перенаправлення застосовуватиме метод GET. |
| 302 |
Запитаний ресурс наразі тимчасово відповідає запиту з різного URI. Оскільки таке перенаправлення є тимчасовим, клієнт повинен продовжувати надсилати подальші запити на стару адресу. Ця відповідь може бути кешованою лише за умови, що вказано в Cache-Control або Expires. Новий тимчасовий URI повинен бути повернутий у заголовку Location. Якщо це не запит HEAD, то тіло відповіді повинно містити гіперпосилання на новий URI, а також короткий опис. Якщо це не запит GET або HEAD, браузер автоматично забороняється перенаправляти, якщо не отримано підтвердження користувача, оскільки умови запиту можуть змінитися. Зверніть увагу: хоча RFC 1945 і RFC 2068 не дозволяють клієнту змінювати метод запиту під час перенаправлення, багато вже наявних браузерів інтерпретують 302 відповіді як відповіді 303 і використовують метод GET для доступу до URI, зазначеного в заголовку місця, нехтуючи початковим методом запиту. Статус-коди 303 і 307 були додані для чіткого вказання на те, яких дій чекає сервер від клієнта. |
| 303 |
Відповідь на поточний запит може бути знайдена під іншим URI, і клієнт слід використовувати метод GET для доступу до цього ресурсу. Включення цього методу в основному призначено для дозволу редиректу результату POST-запиту, що активується скриптами, на новий ресурс. Цей новий URI не є альтернативою оригінальному ресурсу. Відповіді 303 також забороняються від кешу. Безумовно, другий запит (перенаправлений) може бути кешованим. Новий URI повинен бути повернутий у заголовку Location. Якщо це не запит HEAD, то тіло відповіді повинно містити гіперпосилання на новий URI, а також короткий опис. Зверніть увагу: багато браузерів до версії HTTP/1.1 не можуть правильно розуміти статус 303. Якщо ви повинні порозумітися з цими браузерами, статус-код 302 повинен підійти, оскільки більшість браузерів обробляють відповіді 302 згідно специфікації, вказуючи, що клієнт повинен обробити статус 303 як зазначено висше. |
| 304 |
Якщо клієнт надіслав умовний запит GET і цей запит було дозволено, а вміст документа (з моменту останнього відвідування або відповідно до умов запиту) не змінився, сервер повинен повернути цю статус-код. Відповідь 304 забороняє включення тіла повідомлення, тому завжди завершується першим порожнім рядком після заголовків відповіді. Ця відповідь повинна включати такі заголовки: Date, якщо сервер не має годинника. Якщо сервер без годинника також дотримується цих правил, то проміжні сервери й клієнти можуть самостійно додавати поле Date до отриманих заголовків відповіді (як це зазначено в RFC 2068), механізм кешування буде працювати нормально. ETag та/або Content-Location, якщо такий самий запит повинен був повернути 200 відповідь. Expires, Cache-Control та/або Vary, якщо їх значення можуть бути різними в порівнянні з уникненням з іншими відповідями там, де використовуються значення. Якщо цей запит використовував умовну перевірку, ця відповідь не повинна містити інші заголовки; в іншому випадку (наприклад, умовний запит GET, використовуючи слабку перевірку кешу), ця відповідь забороняє включати інші заголовки, щоб уникнути несоответствия між кешованим контентом та оновленими заголовками. Якщо якийсь 304 відповідь вказує, що певна сутність не кешована, тоді система кешу повинна проігнорувати цю відповідь і знову надіслати запит без умов. Якщо отримано відповідь 304, що вимагає оновлення певного кешованого елемента, то система кешу повинна оновити весь елемент, щоб відобразити всі в полях, що обновляються у відповідь. |
| 305 |
Запитуваний ресурс може бути доступний тільки через зазначений проксі. Адреса URI проксі буде вказана в заголовку Location, отримувачу потрібно повторно надіслати окремий запит через цей проксі, щоб отримати відповідний ресурс. Лише оригінальний сервер може згенерувати 305 відповідь. Зверніть увагу: RFC 2068 не чітко визначає, що 305 відповідь призначена для перенаправлення окремого запиту, і може бути згенерована лише оригінальним сервером. Ігнорування цих обмежень може призвести до серйозних проблем з безпекою. |
| 306 |
У новішій специфікації статус-код 306 більше не використовується. |
| 307 |
Запитаний ресурс наразі тимчасово відповідає запиту з різного URI. Оскільки таке перенаправлення є тимчасовим, клієнт повинен продовжувати надсилати подальші запити на стару адресу. Ця відповідь може бути кешованою лише за умови, що вказано в Cache-Control або Expires. Новий тимчасовий URI повинен бути повернутий у заголовку Location. Якщо це не запит HEAD, то тіло відповіді повинно містити гіперпосилання на новий URI, а також короткий опис. Оскільки деякі браузери можуть не розпізнавати 307 відповіді, вказана необхідна інформація має впередити, щоб клієнт зрозумів, що відбулася переміщення до нового URI. Якщо це не запит GET або HEAD, браузер автоматично забороняється перенаправляти, якщо не отримано підтвердження користувача, оскільки умови запиту можуть бути змінені. |
| 400 |
1. Семантика неправильна, і поточний запит не може бути зрозумілим сервером. Без внесення змін, клієнт не повинен повторно подавати цей запит. 2. Неправильні параметри запиту. |
| 401 |
Поточний запит вимагає автентифікації користувача. Ця відповідь повинна містити заголовок WWW-Authenticate для запиту інформації про користувача, відповідного запитаному ресурсу. Клієнт може повторно надсилати запит з відповідним заголовком Authorization. Якщо поточний запит вже містить сертифікати авторизації, тоді 401 відповідь означає, що сервер відхилив ці сертифікати перевірки. Якщо 401 відповідь містить таке ж запит про автентифікації, як і попередня відповідь, і браузер вже спробував принаймні один раз підтвердити автентифікацію, браузер повинен показати інформацію, присутню в тілі відповіді, оскільки ця інформація може містити діагностичні дані. Дивіться RFC 2617. |
| 402 |
Цей статус-код зарезервовано для майбутніх потреб. |
| 403 |
Сервер зрозумів запит, але відмовляється його виконувати. На відміну від 401 відповіді, автентифікація не може допомогти, і цей запит не повинен бути повторно надісланий. Якщо це не запит HEAD, і сервер бажає пояснити, чому запит не може бути виконано, він повинен описати причину відмови в тілі. Звісно, сервер також може повернути 404 відповідь, якщо не бажає надавати клієнту жодної інформації. |
| 404 |
Запит не вдався, ресурс, на який сподівалися, не знайдений на сервері. Немає інформації, щоб повідомити користувача про те, чи є цей стан тимчасовим чи постійним. Якщо сервер знає, що сталося, він повинен використовувати статус-код 410, щоб вказати, що старий ресурс остаточно не доступний через проблему внутрішньої конфігурації, і немає адреси для переадресації. Статус-код 404 широко застосовується, коли сервер не бажає розкривати, чому запит був відхилений або немає інших доречних відповідей. |
| 405 |
Метод запиту, зазначений у рядку запиту, не може бути використаний для запиту відповідного ресурсу. Відповідь повинна повернути заголовок Allow, щоб вказати список методів запиту, які ресурс може приймати. Оскільки методи PUT, DELETE можуть записувати дані на сервері, більшість веб-серверів не підтримують або за умовчанням забороняють ці методи, тому для запитів виникає помилка 405. |
| 406 |
Властивості змісту запитуваного ресурсу не можуть задовольнити умови, вказані у заголовках запиту, тому не може бути згенеровано тіло відповіді. Якщо це не запит HEAD, то відповідь повинна повернути тіло, що містить список властивостей, які можуть дозволити користувачу або браузеру вибрати найбільш підходящу властивість та адресу. Формат цього тіла визначається типом контенту, описаним у заголовку Content-Type. Браузер може самостійно прийняти найкраще рішення на основі формату та своєї здатності. Проте, специфікація не визначає жодні стандарти для проведення такого автоматичного вибору. |
| 407 |
Схоже на 401 відповідь, але клієнт повинен надавати перевірку автентифікації на проксі-сервері. Проксі-сервер повинен повернути заголовок Proxy-Authenticate для запиту автентифікації. Клієнт може надіслати заголовок Proxy-Authorization для перевірки. Дивіться RFC 2617. |
| 408 |
Тайм-аут запиту. Клієнт не завершив відправлення запиту протягом часу, який сервер готовий чекати. Клієнт може знову надіслати цей запит у будь-який час без змін. |
| 409 |
Запит не можна завершити через конфлікт з поточним станом запитуваного ресурсу. Цей код дозволяється використовувати лише у таких випадках, коли користувач вважається здатним вирішити конфлікт і знову надіслати новий запит. Відповідь повинна містити достатню інформацію, щоб допомогти користувачу виявити джерело конфлікту. Конфлікти зазвичай виникають під час обробки запитів PUT. Наприклад, у середовищі з перевірками версій, якщо супроводжений запитом PUT модифікації конкретного ресурсу відомий у запиті версії конфліктує з попереднім запитом, тоді сервер повинен повернути 409 помилку, повідомивши користувача, що запит не може бути виконано. У відповідній сутності, ймовірно, буде включено порівняння відмінностей між двома конфліктуючими версіями, щоб користувач міг заново надіслати узагальнений новий варіант. |
| 410 |
Запитуваний ресурс більше не доступний на сервері і немає жодної відомої адреси для перенаправлення. Цей стан має вважатися постійним. Якщо можливо, клієнти, які мають функцію редагування посилань, повинні після отримання дозволу від користувача видалити всі посилання на цю адресу. Якщо сервер не знає або не може визначити, чи є це станом постійним, то слід використовувати статус-код 404. Якщо не вказано інше, то ця відповідь може бути кешованою. Мета відповіді 410 в основному складається в допомозі адміністраторам веб-сайтів підтримувати їхні сайти, сповіщаючи користувачів про те, що ресурс більше не доступний, і що власник серверу бажає, щоб усі видворені з'єднання, які ведуть до цього ресурсу, були видалені. Такі випадки часто зустрічаються в часових, платних послугах. Також зазвичай 410 відповіді використовуються, щоб повідомити клієнтам, що ресурси, що колись належали конкретній особі, тепер недоступні на даному сервері. Звісно, чи потрібно позначати всі постійно недоступні ресурси статусом '410 Gone', і на який термін їх слід зберігати, повністю залежить від власника сервера. |
| 411 |
Сервер відмовляється приймати запит без визначеного заголовка Content-Length. Після додавання дійсного заголовка Content-Length, що вказує на розмір тіл запитуваного повідомлення, клієнт може повторно надіслати цей запит. |
| 412 |
Сервер не зміг задовольнити одну або декілька із попередніх умов, вказаних в заголовках запиту. Цей статус-код дозволяє клієнту встановлювати вимоги до умов в метаінформації запиту (дані заголовків запиту), щоб уникнути застосування методу запиту до ресурсів, які не відповідають його бажанням. |
| 413 |
Сервер відмовляється обробляти поточний запит, оскільки розмір даних сутності, що надсилається, перевищує межу, яку сервер готовий або здатний обробити. У такому випадку сервер може закрити з'єднання, щоб запобігти клієнту продовжити відправлення цього запиту. Якщо ця ситуація є тимчасовою, сервер повинен повернути заголовок Retry-After, щоб сповістити клієнта, через який період часу дозволено повторна спроба. |
| 414 |
Запитуваний URI перевищує довжину, що сервер здатний обробити, і таким чином сервер відмовляється обслуговувати цей запит. Це відбувається досить рідко, але зазвичай через: форма, що повинна використовувати метод POST, перетворюється в метод GET, в результаті чого надмірна довжина рядка запиту. Бездонні URI перенаправляють, коли URI старий включається в новий URI, що призводить до появи надмірної довжини після декількох переадресацій. Клієнт намагається скористатися якимось відомими вразливостями на сервері. Такі сервери, що використовують буфер сталих довжин для читання або обробки запитів URI, можуть призвести до переповнення буфера та виконання коду, коли параметри, що використовуються в GET, перевищують певну значення. Сервери без подібних вразливостей повинні повертати статус-код 414. |
| 415 |
У запиті з боку доставки контенту між методу запиту та запитуваним ресурсом, подані дані не є форматом, що підтримується сервером, тому запит було відхилено. |
| 416 |
Якщо запит включає заголовок Range, і жоден з вказаних діапазонів не перекриває доступний діапазон ресурсу, і запит не має визначеного заголовка If-Range, то сервер повинен повернути статус-код 416. Якщо діапазон використовує байтові діапазони, ця ситуація означає, що перший байт у вказаному діапазоні запиту перевищує довжину поточного ресурсу. Сервер повинен також включити заголовок Content-Range з цим статус-кодом, щоб вказати довжину поточного ресурсу. Цю відповідь заборонено використовувати для multipart/byteranges в якості Content-Type. |
| 417 |
Вміст, вказаний у заголовку Expect, не може бути задоволено сервером, або ж сервер є проксі, що має очевидні докази того, що це не може бути задоволено на наступному кроці маршруту. |
| 421 |
Кількість з'єднань з поточної IP-адреси клієнта перевищує максимальну дозволену сервером. Зазвичай, ця IP-адреса вказує на клієнтську адресу, яку сервер бачить (наприклад, адреса шлюзу або проксі-сервера). У цьому випадку підрахунок кількості з'єднань може включати більше, ніж один термінал користувача. |
| 422 |
419 Неправильний запит. 420 У вашій проблемі, запит формат правильний, але з семантичними помилками не може бути укладено. (RFC 4918 WebDAV) |
| 424 |
Запит не вдалося завершити через помилку в одному з попередніх запитів, наприклад PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Визначено в проекті WebDav Advanced Collections, але не з'являється в "WebDAV Sequential Collection Protocol" (RFC 3658). |
| 426 |
Клієнт має перейти на TLS/1.0. (RFC 2817) |
| 449 |
Розширеною Microsoft, представляє, що запит має бути повторно надіслано після виконання відповідної операції. |
| 500 |
Сервер зіткнувся з непередбаченою ситуацією, що унеможливлює його обробку запиту. Зазвичай, ця проблема виникає під час помилок у коді сервера. |
| 501 |
Сервер не підтримує певну функцію, необхідну для поточного запиту. Коли сервер не може визнати метод запиту і не може підтримувати його для жодного ресурсу. |
| 502 |
Сервер, що діє як шлюз або проксі, отримує недійсну відповідь під час намагання виконати запит із серверу, що стоїть вище за ним. |
| 503 |
У зв'язку з тимчасовими обслуговуваннями або перевантаженням сервер наразі не може обробити запит. Це тимчасовий стан, і він відновиться через деякий час. Якщо є можливість оцінити затримку, відповідь може включати заголовок Retry-After для вказування цього часу затримки. Якщо не вказано інформацію Retry-After, клієнт повинен обробляти цю відповідь так, як обробляти 500 відповідь. Зверніть увагу: наявність статусу 503 не означає, що сервер повинен його використовувати під час перевантаження. Деякі сервери просто хочуть відмовити з'єднанню клієнта. |
| 504 |
Сервер, що виконує запит як шлюз або проксі, не зміг отримати відповідь від перевіреного сервера (сервера, що ідентифікується URI, наприклад HTTP, FTP, LDAP) або допоміжного сервера (наприклад DNS) під час виконання запиту. Зверніть увагу: деякі проксі-сервери повертають помилки 400 або 500 під час перевірки DNS. |
| 505 |
Сервер не підтримує або відмовляється підтримувати версію HTTP, використовувану в запиті. Це означає, що сервер не може або не хоче використовувати таку ж версію, як у клієнта. Відповідь повинна включати опис, по якій причини версія не підтримується, і які протоколи підтримує сервер. |
| 506 |
Згідно "Протоколу узгодження вмісту" (RFC 2295), представляє наявність внутрішньої помилки в конфігурації сервера: запитаний ресурс конфігуровано для використання самому собі в отриманні одного з попередніх результатів. |
| 507 |
Сервер не може зберегти вміст, необхідний для завершення запиту.Це вважається тимчасовим станом. WebDAV(RFC 4918) |
| 509 |
Сервер досягнув обмежень по пропускній здатності. Це не є офіційним статус-кодом, але все ще широко використовується. |
| 510 |
Політика, необхідна для отримання ресурсу, не була задоволена. (RFC 2774) |