| Код статусу Http | Код статусу Значення |
|---|
| 100 | Клієнт повинен продовжувати надсилати запити. Ця тимчасова відповідь використовується для інформування клієнта про те, що частина його запиту була отримана сервером і не була відхилена. Клієнт повинен продовжувати надсилати решту запиту або проігнорувати цю відповідь, якщо запит завершено. Сервер повинен надіслати клієнту остаточну відповідь, коли запит буде завершено. |
| 101 | Сервер зрозумів запит клієнта і повідомить його за допомогою заголовка повідомлення Upgrade про необхідність використання іншого протоколу для завершення запиту. Після надсилання останнього порожнього рядка цієї відповіді сервер переключиться на протоколи, визначені в заголовку повідомлення Upgrade. Це слід робити тільки в тому випадку, якщо перехід на новий протокол є більш вигідним. Наприклад, перехід на нову версію HTTP є більш вигідним, ніж на стару версію, або перехід на протокол реального часу і синхронний протокол для доставки ресурсів, які використовують переваги таких можливостей. |
| 102 | Коди стану, розширені WebDAV (RFC 2518), показують, що обробка буде продовжена. |
| 200 | Запит було успішно виконано, і заголовок відповіді або тіло даних, які вимагалися в запиті, буде повернуто разом з цією відповіддю. |
| 201 | Запит виконано, новий ресурс створено відповідно до запиту, і його URI повернуто разом із заголовком Location. Якщо потрібний ресурс не може бути створений вчасно, слід повернути "202 Прийнято". |
| 202 | Сервер прийняв запит, але ще не обробив його. Так само, як він може бути відхилений, в кінцевому підсумку запит може бути виконаний, а може і не бути виконаний. У контексті асинхронних операцій немає нічого зручнішого, ніж надсилання цього коду стану. Мета повернення відповіді з кодом стану 202 полягає в тому, щоб дозволити серверу приймати запити від інших процесів (таких як пакетна операція, яка виконується тільки один раз на день) без необхідності тримати клієнта на зв'язку з сервером, поки пакетна операція не буде повністю завершена. Відповідь, яка приймає запит на обробку і повертає код стану 202, ПОВИННА містити в повернутій сутності деяку інформацію, що вказує на поточний стан процесу, а також вказівник на монітор стану обробки або прогнозування стану, щоб користувач міг оцінити, чи завершилася операція. |
| 203 | Сервер успішно обробив запит, але метаінформація в заголовку сутності, що повертається, не є остаточним набором, дійсним на оригінальному сервері, а є копією з локального або стороннього сервера. Поточна інформація може бути підмножиною або надмножиною оригінальної версії. Наприклад, метадані, що містять ресурси, можуть призвести до того, що оригінальний сервер знатиме метаінформацію super. Використання цього коду статусу не є обов'язковим і доречне лише в тому випадку, якщо без нього відповідь повернула б 200 OK. |
| 204 | Сервер успішно обробив запит, але йому не потрібно повертати фізичний вміст і він хоче повернути оновлену метаінформацію. У відповіді може бути повернута нова або оновлена метаінформація у вигляді заголовків сутностей. Якщо такі заголовки існують, вони повинні відповідати запитуваним змінним. Якщо клієнтом є браузер, то браузер користувача ПОВИНЕН зберегти сторінку, на якій було надіслано запит, без зміни вигляду документа, навіть якщо згідно зі специфікацією нова або оновлена метаінформація ПОВИННА бути застосована до документа в активному вікні браузера користувача. Оскільки у відповіді 204 заборонено містити будь-яке тіло повідомлення, вона завжди закінчується першим порожнім рядком після заголовка повідомлення. |
| 205 | Сервер успішно обробив запит і нічого не повернув. Однак, на відміну від відповіді 204, відповідь, яка повертає цей код стану, просить запитувача скинути перегляд документа. Ця відповідь в основному використовується для скидання форми відразу після прийняття даних, щоб користувач міг легко почати вводити нові дані. Як і відповідь 204, ця відповідь не повинна містити тіло повідомлення і закінчується першим порожнім рядком після заголовка повідомлення. |
| 206 | Сервер успішно обробив частину GET-запиту. HTTP-інструменти для завантаження, такі як FlashGet або Thunderbolt, використовують цей тип відповіді для виконання переривчастих завантажень або для розбиття великого документа на кілька сегментів для одночасного завантаження. Запит повинен містити заголовок Range, щоб вказати діапазон вмісту, який клієнт бажає отримати, і може містити If-Range як умову запиту. Відповідь повинна містити такі поля заголовка: Content-Range для позначення обсягу вмісту, що повертається у цій відповіді; у випадку багатосегментного завантаження з типом Content-Type multipart/byteranges, кожен багатосегментний сегмент повинен містити поле Content-Range, що вказує на обсяг вмісту в цьому сегменті. Якщо відповідь містить Content-Length, її значення має відповідати дійсній кількості байт у діапазоні вмісту, який вона повертає. дата ETag та/або Content-Location, якщо той самий запит мав би повернути відповідь 200. Expires, Cache-Control та/або Vary, якщо їхні значення можуть відрізнятися від інших відповідей з тими самими змінними. Expires, Cache-Control і/або Vary, якщо їх значення можуть відрізнятися від значень інших попередніх відповідей для тих же змінних. Ця відповідь НЕ ПОВИННА містити інших заголовків сутностей, якщо запит використовує сильну перевірку кешу If-Range, і НЕ ПОВИННА містити інших заголовків сутностей, якщо запит використовує слабку перевірку кешу If-Range; це дозволяє уникнути невідповідностей між кешованим вмістом сутності та оновленою інформацією заголовків сутності. В іншому випадку ця відповідь ПОВИННА містити всі поля заголовка сутності, які мали бути повернуті у всіх 200 відповідях, які мали бути повернуті. Якщо заголовки ETag або Last-Modified не збігаються точно, кеш на стороні клієнта ПОВИНЕН заборонити об'єднання вмісту, повернутого у відповіді 206, з будь-яким раніше закешованим вмістом. Будь-якому кешу, який не підтримує заголовки Range і Content-Range, заборонено кешувати вміст, що повертається у відповіді 206. |
| 207 | Код статусу, розширений WebDAV (RFC 2518), означає, що наступне тіло повідомлення буде 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 Expires, Cache-Control та/або Vary, якщо значення може відрізнятися від значення, що відповідає іншим попереднім відповідям для тієї ж змінної. Якщо в цьому запиті використовується сильна перевірка кешу, то ця відповідь не повинна містити інших заголовків сутностей; в іншому випадку (наприклад, в умовному GET-запиті використовується слабка перевірка кешу), цій відповіді заборонено містити інші заголовки сутностей; це дозволяє уникнути невідповідностей між кешованим вмістом сутності та оновленою інформацією заголовка сутності. Якщо відповідь 304 вказує на те, що сутність наразі не кешована, система кешування повинна проігнорувати відповідь і повторити запит без обмежень. Якщо отримано відповідь 304 із запитом на оновлення запису в кеші, система кешування ПОВИННА оновити весь запис, щоб відобразити значення всіх полів, оновлених у відповіді. |
| 305 | Доступ до запитуваного ресурсу повинен здійснюватися через вказаний проксі-сервер. У полі "Розташування" буде надано інформацію про 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-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 після декількох перенаправлень. Клієнти намагаються атакувати сервери, використовуючи уразливості в безпеці, які існують на деяких серверах. Такі сервери використовують буфер фіксованої довжини для читання або маніпулювання 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 Locked Поточний ресурс заблоковано. (RFC 4918 WebDAV) |
| 424 | Поточний запит не вдалося виконати через помилку, що сталася в попередньому запиті, наприклад, PROPPATCH.(RFC 4918 WebDAV) |
| 425 | Визначено в проекті розширених колекцій WebDav, але не з'являється в протоколі послідовних колекцій WebDAV (RFC 3658). |
| 426 | Клієнтам слід перейти на TLS/1.0 (RFC 2817). |
| 449 | Розширено корпорацією Майкрософт для позначення того, що запити повинні бути повторені після виконання відповідної дії. |
| 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) |