Онлайн инструменти
Кодове за състоянието на 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, неговата стойност трябва да съответства на действителния брой байтове в обхвата на върнатото съдържание. 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 заявка, отговорът трябва да включва същност, която представлява списък от характеристики на ресурса и адреси, от които потребителят или браузърът може да избере най-подходящия адрес за пренасочване. Форматът на тази същност се определя от формата на определението за 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, 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-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, което води до дълъг 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) 423 Locked
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)
Достъп до документи: