| Код на състоянието на 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 (Тип на съдържанието) от 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 заявка, отговорът трябва да включва същност, която представлява списък от характеристики на ресурса и адреси, от които потребителят или браузърът може да избере най-подходящия адрес за пренасочване. Форматът на тази същност се определя от формата на определението за Content-Type. Браузърът може автоматично да направи най-подходящия избор въз основа на формата на отговора и собствените възможности на браузъра. Разбира се, в спецификацията RFC 2616 не е посочено как трябва да се направи такъв автоматичен избор. Ако самият сървър вече има предпочитан избор на връщане, тогава URI на това връщане трябва да се посочи в Location (Местоположение); браузърът може да използва тази стойност на Location (Местоположение) като адрес за автоматично пренасочване. Освен това този отговор може да се кешира, освен ако не е посочено друго. |
| 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 към заглавието на входящия отговор (както е посочено в RFC 2068) и механизмът за кеширане ще работи правилно.ETag и/или Content-Location, ако същата заявка би върнала отговор 200.Expires 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 за искания ресурс, за да поиска информация за потребителя. Клиентът може многократно да подаде заявка, която съдържа съответната информация от заглавието Authorisation. Ако текущата заявка вече съдържа данни за оторизация, тогава отговорът 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, което води до дълъг Query String. "Черни дупки" на URI при пренасочване, като например използване на стария URI като част от новия URI при всяко пренасочване, което води до дълъг URI след няколко пренасочвания. Клиентите се опитват да атакуват сървъри, като използват уязвимости в сигурността, които съществуват в някои сървъри. Такива сървъри използват буфер с фиксирана дължина, за да четат или манипулират URI на заявката, и когато параметрите след GET надвишават определена стойност, може да се получи препълване на буфера, което да доведе до изпълнение на произволен код [1]. Сървърите без такива уязвимости трябва да връщат код на състоянието 414. |
| 415 | За текущо заявения метод и заявения ресурс подадената в заявката същност не е във формат, поддържан от сървъра, поради което заявката се отхвърля. |
| 416 | Ако заявката съдържа заглавие на заявка Range (Обхват) и всички диапазони от данни, посочени в Range (Обхват), не се припокриват с диапазоните, налични за текущия ресурс, и заглавието на заявката If-Range (Обхват) не е дефинирано в заявката, тогава сървърът трябва да върне код на състоянието 416. Ако Range използва байтови диапазони, тогава това е така, ако първата байтова позиция на всички диапазони от данни, посочени в заявката, надвишава дължината на текущия ресурс. Сървърът трябва също така да включи заглавие на ентитета Content-Range (Обхват на съдържанието), което посочва дължината на текущия ресурс заедно с кода за състояние 416. На този отговор също така е забранено да използва multipart/byteranges като свой 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 | Разширена от 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) |