Код стану HTTP - це 3-значний код, який поверта?ться сервером у в?дпов?дь на запит ? використову?ться для ?дентиф?кац?? результату запиту. Цей ?нструмент нада? стандартизовану класиф?кац?ю та ?нтерпретац?ю сценар??в, що п?дходить для розробник?в, експлуатац?йного та техн?чного персоналу, а також для тих, хто вивча? мережев? технолог??.
Вс? пояснення базуються на стандартному документ? RFC, уникаючи рег?ональних в?дм?нностей у вираженн? та гарантуючи, що користувач? по всьому св?ту розум?ють однаково.
| Коди стану 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) |