Онлайн-інструменти
Коди стану 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 або Thunderbolt, використовують цей тип відповіді для виконання переривчастих завантажень або для розбиття великого файлу на кілька завантажень одночасно. Запит повинен містити заголовок Range, щоб вказати діапазон вмісту, який клієнт бажає отримати, і може містити If-Range як умову запиту. Відповідь повинна містити такі поля заголовка: Content-Range для позначення діапазону вмісту, повернутого у цій відповіді, або, у випадку багаточастинних завантажень з типом Content-Type багаточастинне/розбите на частини, поле Content-Range у кожному багаточастинному сегменті для позначення діапазону вмісту у цьому сегменті. Якщо відповідь містить Content-Length, її значення має відповідати дійсній кількості байт у діапазоні вмісту, який вона повертає. Expires, Cache-Control і/або Vary, якщо їх значення можуть відрізнятися від значень інших попередніх відповідей з тими ж змінними. Ця відповідь не повинна містити інших заголовків сутностей, якщо запит використовує сильну перевірку кешу If-Range, і не повинна містити інших заголовків сутностей, якщо запит використовує слабку перевірку кешу If-Range; це дозволяє уникнути невідповідностей між кешованим вмістом сутності та оновленою інформацією заголовка сутності. В іншому випадку ця відповідь ПОВИННА містити всі поля заголовка сутності, які мали бути повернуті у відповіді 200. Якщо заголовки ETag або Last-Modified не збігаються точно, кеш на стороні клієнта повинен заборонити об'єднання вмісту, повернутого у відповіді 206, з будь-яким раніше закешованим вмістом. Будь-якому кешу, який не підтримує заголовки Range і Content-Range, заборонено кешувати вміст, що повертається у відповіді 206.
207 Коди стану, розширені WebDAV(RFC 2518) Код статусу, розширений WebDAV, означає, що наступне тіло повідомлення буде XML-повідомленням і може містити серію окремих кодів відповіді, залежно від кількості попередніх підзапитів.
300 Запитуваний ресурс має низку альтернативних відповідей, кожна з яких має власну конкретну адресу та інформацію для переговорів, що визначається браузером. Вибір адреси для перенаправлення залежить від користувача або браузера. Якщо це не HEAD-запит, відповідь повинна містити сутність, яка є списком характеристик ресурсу та адрес, з яких користувач або браузер може вибрати найбільш підходящу адресу перенаправлення. Формат цієї сутності визначається форматом визначення типу контенту. Браузер може автоматично зробити найбільш відповідний вибір на основі формату відповіді і власних можливостей браузера. Звичайно, специфікація RFC 2616 не визначає, як саме має відбуватися цей автоматичний вибір. Якщо сам сервер вже має бажаний варіант повернення, URI цього повернення слід вказати в Location; браузери можуть використовувати це значення Location як адресу для автоматичного перенаправлення. Крім того, відповідь можна кешувати, якщо не вказано інше.
301 Запитуваний ресурс назавжди переміщено на нове місце, і будь-які подальші посилання на нього повинні використовувати один з декількох URI, повернутих у цій відповіді. Якщо можливо, клієнти з можливостями редагування посилань повинні автоматично змінювати запитувану адресу на ту, яку повернув сервер. Цю відповідь також можна кешувати, якщо не вказано інше. Новий постійний URI має бути повернутий у полі "Місцезнаходження" відповіді. Якщо це не 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, зазначеного в полі Location, ігноруючи метод початкового запиту. Коди статусу 303 і 307 були додані, щоб пояснити, яку відповідь сервер очікує від клієнта.
303 Відповідь на поточний запит можна знайти за іншою URI, і клієнт повинен отримати доступ до цього ресурсу за допомогою GET. Цей метод існує головним чином для того, щоб дозволити перенаправляти результати POST-запиту, активованого скриптом, на новий ресурс. Цей новий URI не є заміною посилання на оригінальний ресурс. Крім того, відповідь 303 не можна кешувати. Звичайно, другий запит (перенаправлення) можна кешувати. Новий URI повинен бути повернутий у полі Location відповіді. Якщо це не HEAD-запит, сутність відповіді повинна містити гіперпосилання на новий URI і короткий опис. Примітка: Багато браузерів до версії HTTP/1.1 неправильно розуміють стан 303. Якщо необхідно враховувати взаємодію з цими браузерами, код стану 302 повинен працювати, оскільки більшість браузерів обробляють відповідь 302 точно так само, як специфікація вище вимагає від клієнта обробляти відповідь 303.
304 Цей код статусу повинен бути повернутий сервером, якщо клієнт відправив умовний GET-запит і запит дозволений, а вміст документа не змінився (ні з моменту останнього відвідування, ні відповідно до умов запиту). 304 відповіді заборонено містити тіло повідомлення, і тому вони завжди закінчуються першим порожнім рядком після заголовка повідомлення. Відповідь повинна містити наступну інформацію в заголовку: Дата, якщо на сервері немає годинника. Якщо сервер без годинника дотримується цих правил, то проксі-сервер і клієнт можуть самостійно додавати поле Date до заголовка вхідної відповіді (як зазначено в RFC 2068), і механізм кешування буде працювати належним чином.ETag і/або Content-Location, якщо той самий запит повинен був повернути відповідь 200. Expires, Cache-Control і/або Vary, якщо їх значення можуть відрізнятися від значень інших попередніх відповідей з тими ж змінними. Якщо у відповіді використовується сильна перевірка кешу, то відповідь не повинна містити додаткових заголовків сутностей; в іншому випадку (наприклад, умовний GET-запит використовує слабку перевірку кешу), у відповіді заборонено містити додаткові заголовки сутностей; це дозволяє уникнути невідповідностей між вмістом кешованих сутностей та оновленою інформацією про заголовки сутностей. Якщо відповідь 304 вказує на те, що сутність наразі не кешована, система кешування повинна проігнорувати відповідь і повторити запит без обмежень. Якщо отримано відповідь 304 із запитом на оновлення запису в кеші, система кешування ПОВИННА оновити весь запис, щоб відобразити значення всіх полів, оновлених у відповіді.
305 Доступ до запитуваного ресурсу повинен здійснюватися через вказаний проксі-сервер. У полі Location буде вказано URI вказаного проксі-сервера, і одержувачу потрібно буде повторно надіслати окремий запит, щоб отримати доступ до ресурсу через цей проксі-сервер. Тільки оригінальний сервер може створити відповідь 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 для запитуваного ресурсу, який запитує інформацію про користувача. Клієнт може повторно надіслати запит з відповідним заголовком авторизації. Якщо поточний запит вже містить авторизаційні дані, то відповідь 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-Authorisation для автентифікації. Зверніться до 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 після декількох перенаправлень. Клієнти намагаються атакувати сервери, використовуючи вразливості в безпеці, які існують на деяких серверах. Такі сервери використовують буфер фіксованої довжини для читання або маніпулювання запитуваним URI, що може призвести до переповнення буфера, коли параметр GET перевищує певне значення, що призводить до довільного виконання коду.[1]。 Сервери без таких уразливостей повинні повертати код стану 414.
415 Для поточного запитуваного методу і запитуваного ресурсу сутність, передана в запиті, не має формату, що підтримується сервером, і запит відхиляється.
416 Якщо запит містить заголовок запиту Range, і будь-які діапазони даних, зазначені в Range, не збігаються з діапазонами, доступними для поточного ресурсу, а заголовок запиту If-Range не визначено в запиті, то сервер повинен повернути код стану 416. Якщо Range використовує байтовий діапазон, то це означає, що перший байт усіх діапазонів даних, зазначених у запиті, перевищує довжину поточного ресурсу. Сервер також повинен включити заголовок сутності Content-Range, який вказує довжину поточного ресурсу разом з кодом стану 416. У цій відповіді також заборонено використовувати мультичастинні/байтерні значення типу Content-Type.
417 Очікуваний вміст, зазначений у заголовку запиту Expect, не може бути виконаний сервером, або сервер є проксі-сервером, який має чіткі докази того, що вміст Expect не може бути виконаний на наступному вузлі в поточному маршруті.
421 Кількість з'єднань з сервером з IP-адреси поточного клієнта перевищує максимально дозволену сервером. Зазвичай під IP-адресою тут мається на увазі адреса клієнта, яку бачить сервер (наприклад, адреса шлюзу користувача або проксі-сервера). У цьому випадку в підрахунку з'єднань може брати участь більше одного кінцевого користувача.
422 Кількість з'єднань з поточної IP-адреси клієнта до сервера перевищує максимально дозволену сервером. Зазвичай під IP-адресою тут мається на увазі адреса клієнта, яку бачить сервер (наприклад, адреса шлюзу користувача або проксі-сервера). У цьому випадку в підрахунку з'єднань може брати участь більше одного кінцевого користувача.
422 Запит було відформатовано правильно, але на нього неможливо відповісти, оскільки він містить семантичні помилки. (RFC 4918 WebDAV) 423 Заблоковано Поточний ресурс заблоковано. (RFC 4918 WebDAV) 423 Заблоковано
424 Поточний запит не вдалося виконати через помилку в попередньому запиті, наприклад, PROPPATCH. (RFC 4918 WebDAV)
425 Визначено в проекті розширених колекцій WebDav, але не з'являється в протоколі послідовних колекцій WebDAV (RFC 3658).
426 Клієнти повинні перейти на TLS/1.0 (RFC 2817).
449 Розширено Microsoft для позначення того, що запити повинні бути повторені після виконання відповідної дії.
500 Сервер зіткнувся з непередбаченою умовою, яка не дозволила йому завершити обробку запиту. Зазвичай ця проблема виникає, коли в програмному коді сервера є помилка.
501 Сервер не підтримує функцію, необхідну для поточного запиту. Коли сервер не розпізнає запитуваний метод і не може підтримати запит до будь-якого ресурсу.
502 Сервер, що працює як шлюз або проксі-сервер, отримує недійсну відповідь від попереднього сервера, коли намагається виконати запит.
503 Сервер наразі не може обробити запит через тимчасове технічне обслуговування або перевантаження. Цей стан тимчасовий і буде відновлений через деякий час. Якщо очікується затримка, відповідь може містити заголовок 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)
Доступ до записів: