HTTP кодове за състояние: всеки списък с възможен код

Разкриване на информация Вашата поддръжка помага за поддържането на сайта! Печелим такса за препращане за някои от услугите, които препоръчваме на тази страница.


Contents

Основни кодове на състоянието на HTTP

Повечето хора не мислят прекалено много за това, което всъщност се случва, когато преминават към уеб страница. Те просто отварят браузъра си, щракват върху нещо и там е на екрана ми!

Търсите конкретен код? Разгледайте съдържанието вдясно!

Предпочитаме да не мислим за сложния танц на искания и отговори, случващи се между уеб браузъра на нашия компютър и сървър далеч, в център за данни, невидим (обикновено) дори от системния администратор на уебсайта и ИТ персонала.

Но тогава от време на време се сблъскваме с грешка. Получаваме умна страница 404 Not Found със забавна картинка. Или получаваме празна страница с бележка от собствения ни браузър, която ни казва за някаква неизвестна грешка 501.

Като случаен посетител на уебсайт това е просто досадно. Обикновено опитваме отново – опресняване, връщане назад, щракнете отново. Понякога работи – ние наричаме този проблем и незабавно забравяме за него. Понякога не работи – наричаме го „лош уебсайт“ и обикновено незабавно забравяме и за това.

Но ако всъщност имате уебсайт – това променя всичко. HTTP грешките не са досадни. Те полудяват. Те са неудобни.

Ако сте особено умели или имате добър ИТ екип, това може да не е толкова голяма работа. Повечето подобни проблеми са лесни за отстраняване. Но ако сте собственик на малък бизнес, поддържате свой собствен уебсайт, HTTP състоянието и кодовете за грешки могат да ви подлудят.

Как да коригирате HTTP грешки? Как да избегнете HTTP грешки? Какво означават всички тези кодове за HTTP статус?

Ето какво обхваща настоящото ръководство, заедно с информация за:

  • добри HTTP кодове за състояние (тези, които обикновено не виждате)
  • полезни кодове за състоянието на HTTP
  • какъв тип пренасочвания трябва да използвате (и защо).

Но първо, за да разберете кодовете на състоянието на HTTP, трябва да разберете как HTTP работи на първо място.

HTTP заявки и отговори

HTTP означава „HyperText Transfer Protocol“.

Какво е протокол?

Когато се качвате на морски кораб, има определен начин да направите нещата. Първо поздравяваш знамето, след това поздравяваш дежурния офицер, след което искаш разрешение за качване.

Това е протокол.

Протоколът е набор от правила за определен тип взаимодействие.

Понякога един протокол е много твърд и дефиниран:

  • За да се качите на кораб:
    • Поздравителен флаг
    • Дежурен поздравен офицер
    • Поискайте разрешение за качване.

Понякога протоколите са малко по-разхлабени и неписани, но все още добре познати:

  • Когато пристигне тортата ви за рожден ден:
    • Изчакайте всички да завършат пеенето
    • Пожелай си нещо
    • Издухайте свещите, за предпочитане на един дъх.

Компютърните взаимодействия са свързани с протоколи. Когато два компютъра (или мрежа от компютри) разговарят помежду си, те трябва да имат набор от добре дефинирани правила за комуникация.

Правилата за това как уеб браузърът на вашия локален компютър комуникира с уеб сървъра, който е домакин на сайта, който се опитвате да разгледате, е HTTP (HyperText Transfer Protocol).

Защо прехвърляме HyperText?

Първоначално уеб страниците са предимно документи. „Уеб страница“ се смяташе за действителна „страница“. Сайтът представляваше колекция от документи. Основната страница за даден сайт беше „индекс“ на наличните документи.

Какъв тип документи? Документи с хипертекст.

Хипертекстът означава, че документите се свързват помежду си с „хипервръзки“. Днес просто ги наричаме обикновени „връзки“ – те са толкова обикновени сега, че вече не ги наричаме „хипер“.

Кликващи „хипер“ връзки в текста – тази идея, която е толкова често срещана в момента, беше толкова революционна, когато за първи път се създаде инернетът, че всичко беше кръстено на нея.

Езикът за създаване на тези документи? Език за маркиране на хипертекст (HTML). А протоколът за искане и получаване на тези документи? HTTP.

Значи HTTP е …

HTTP е набор от правила и процедури за това как уеб браузър (или друг „клиент“) изисква ресурси от друг компютър („сървърът“) и как този друг компютър отговаря на тези искания.

HTTP Заявка

Така че, когато въведете адрес, щракнете върху връзка или по друг начин отворите уеб страница, браузърът ви изпраща заявка до друг сървър.

Целта на заявката се определя от URL и DNS системата. Системата DNS е тема за друг ден, но в основата си – DNS е адресна книга, която съответства на имена на домейни с конкретни компютърни IP адреси.

Целта на заявката се определя от името на домейна и целият URL адрес е най-важната част от заявката – всичко след името на домейна казва на сървъра конкретния ресурс, който се иска. Искането съдържа и друга информация като:

  • Типът на заявката Двете най-често срещани са:
    • GET – „Моля, изпратете ми този ресурс.“
    • POST – „Ето някои данни за обработка.“
  • Поля на заглавките – незадължителни полета за метаданни, използвани за уведомяване на сървъра за клиента (какъв тип браузър, например).
  • Body – Данните, изпратени от клиента (за използване с POST).

Сървърът получава тази заявка и (след известна обработка) изпраща отговор.

HTTP отговор

Първият ред на отговора е HTTP статус.

Редът на състоянието има две части, цифров код (като 200) и текстово обяснение (като Успех).

Когато всичко работи добре, получавате статуса на 200: Успех (който вие като човешки потребител никога не виждате), след това някои данни в заглавката (които вие също не виждате) и след това заявения от вас ресурс (което е това, което виждате ).

Ресурсът може да бъде цяла уеб страница, изображение, видео, звуков файл. Може също да е нещо, което не виждате, като JavaScript файл или таблица стилове.

Когато нещата не вървят толкова добре, може да видите съобщение за състоянието. Обикновено това се случва, когато получите нещо като код 404 или 501. Това са кодове за грешки. Нещо се обърка.

Отговорите с 404 или 501 кодове за грешки не се връщат с искания от вас ресурс. Понякога те се връщат с различен ресурс (като умната страница 404). Понякога изобщо няма ресурс (това е, когато получите празната страница на браузъра и съобщението за грешка по подразбиране).

Има и кодове на състоянието, които казват на браузъра да търси някъде другаде, като пренасочването 301. Тези отговори също не идват на искания ресурс.

Вместо това данните от заглавката казват на браузъра да направи нова заявка с някакъв друг URL адрес. Обикновено не забелязвате кога това се случва, защото браузърът ви изпълнява точно казаното и прави втората заявка.

След това ви показва ресурса от втория отговор, без да ви казва, че нещо се е случило. Кодовете за пренасочване на отговорите обикновено нямат значение за крайните потребители, но те трябва да имат голямо значение за администраторите на уебсайтове.

Класове на статус код

Вероятно сте забелязали, че всички кодове на състоянието са трицифрени числа. Забелязахте ли, че първата цифра винаги е между 1 и 5?

Кодовете на състоянието са групирани в пет „класа” от кодове. Грешката 404: Не е намерена е част от 400 (или понякога 4xx) клас на кодовете на състоянието. Всеки клас обхваща определен набор от въпроси или състояния.

  • 1xx – информационни – Това са временни отговори, предназначени да се използват, докато сървърът продължава да обработва заявката. Те рядко се използват.
  • 2xx – Успех – Кодове, използвани, когато нещата работят така, както трябва. Различните кодове за успех се връщат въз основа на това, което конкретно се опита да направи заявката.
  • 3xx – Пренасочване – Кодове, използвани да кажат на клиента да търси искания ресурс някъде другаде.
  • 4xx – клиентска грешка – тези кодове казват на клиента, че е направил нещо нередно.
  • 5xx – Грешка в сървъра – Код за това, когато нещо на сървъра не работи както се очаква.

Ще обхванем специфичните кодове от всеки клас по-задълбочено в техните собствени раздели.

Справяне със кодове на HTTP статус (и грешки)

Това ръководство обхваща всички възможни състояния на HTTP и кодове за грешки в HTTP – от общото до никога използваното. Ще обясним какво означава всеки код, защо се генерират, кода може да е проблем и как да се справим с проблемите.

HTTP статус код 1xx – информационен

Знанието е сила. Информацията е освобождаваща.

– Кофи Анан

HTTP състоянията кодове в клас 1xx са предназначени да бъдат временни, изпратени от сървъра преди да бъде изпратен пълен и завършен втори отговор.

Те бяха въведени в HTTP / 1.1, така че ранните браузъри, внедряващи HTTP / 1.0, не могат да се справят с тях и в тези случаи сървърите не трябва да завършват 1xx кодове.

HTTP 100 Продължете

Обикновено последователността заявка-отговор е ясна. Една-единствена заявка се отправя, получава и отговаря на.

Но понякога една молба трябва да бъде разбита на части. Това може да възникне, ако заявката е твърде голяма. Може да възникне, ако заявителят трябва да провери дали заглавката е форматирана правилно или дали сървърът действително е готов да получи заявката.

В тези случаи клиентът (браузърът) може да изпрати първоначалната заявка с заглавка, която включва Очаквайте: 100-продължение.

Когато това се случи, сървърът ще получи първоначалната заявка и – ако всичко е наред – ще отговори със статуса 100: Продължи. Това сигнализира на клиента да изпълни заявката.

Ако всичко не се получи, сървърът ще изпрати обратно 417 Очакване неуспешно.

HTTP 101 протоколи за превключване

Клиентът може да поиска от сървъра да превключи протоколи, например от HTTP / 1.1 към HTTP / 2.0.

Ако сървърът желае да се съобрази с тази заявка, той ще изпрати обратно отговора 101: Превключване на протоколи, заедно с данни от заглавието, включващо името на новия протокол, който се използва.

HTTP 102 обработка

Този код се използва само с WebDAV, което е разширение на HTTP, което осигурява способност за манипулиране на файлове, донякъде подобна на FTP (макар и много различна в действителната им реализация).

Заявката за WebDAV може да включва много под-заявки. Състоянието 102: Обработка позволява на клиента да знае, че сървърът е получил заявката и работи по нея, но все още има работа. Това не позволява на клиента да приеме, че заявката е загубена и да изтече времето.

HTTP статус код 2xx – успех

Всичко, от което се нуждаете в този живот, е невежеството и увереността и тогава успехът е сигурен.

-Марк Твен

HTTP състоянията кодове в клас 2xx са предназначени да се използват, когато заявката приключи по предназначение.

Много от тези кодове никога не се използват или рядко се използват или дори се прилагат.

HTTP 200 OK

Това е стандартният отговор за успешни заявки – това е кодът на състоянието, който обикновено искате и очаквате.

Когато заявката е GET (пита за ресурс), отговорът ще включва ресурса. Когато заявката е POST (или друг тип), отговорът ще съдържа ресурс, който описва или съдържа резултата от действието.

HTTP 201 Създаден

Някои искания са предназначени за създаване на нов ресурс. Когато те приключат успешно, състоянието 201 се изпраща, което показва, че новият ресурс е създаден. Това обикновено се използва във връзка с типа PUT заявка.

HTTP 202 Прието

Искането е прието, но не е предприето действие. Искането може да бъде предприето или не може да бъде предприето.

HTTP 203 Неавторизирана информация

Отговорът съдържа искания ресурс, но ресурсът може да е получен от друг източник и следователно може да е ненадежден – сървърът не ваучи за валидността или автентичността на ресурса.

HTTP 204 Без съдържание

Той се изпраща, когато сървърът е обработил успешно заявката, но не е необходимо да връща съдържание. Най-често това се случва в резултат на DELETE заявка.

Когато е изпратена заявка 204, агентът на потребителя (клиентът или уеб браузърът) не трябва да променя своя изглед.

Например, ако заявката е изпратена чрез формуляр на страница, отговорът не трябва да доведе до опресняване на формата или браузърът да посети друга страница – няма ново съдържание в заявката за замяна на съществуващото съдържание в потребителя изглед.

HTTP 205 Нулиране на съдържанието

Отговорът 205 е подобен на 204, но се предполага, че агентът на потребителя ще опресни изгледа си обратно състоянието по подразбиране на текущия документ.

Частично съдържание на HTTP 206

Това се използва, когато сървърът изпраща само част от искания ресурс, тъй като потребителят е поискал да получи само част от ресурса.

Това се случва, когато ресурсът е достатъчно голям или връзката е достатъчно ненадеждна, че агентът на потребителя иска да раздели ресурса на поредица от „откъснати“ заявки, както е илюстрирано:

  • Клиент: Дайте ми първата 1/4.
    • Сървър: 206 Частично съдържание
  • Клиент: Дайте ми втория

    1/4.

    • Сървър: 206 Частично съдържание.
  • И така нататък…
    • …и т.н.

Тези частични заявки се извършват от клиента, като се използва заглавката на обхвата. Те могат да се появят една след друга (за да се предпазят от неуспех при изтегляне) или наведнъж в няколко нишки (за да се ускори изтеглянето).

HTTP 207 Multi-Status

Подобно на 103, това се използва само с WebDAV.

Заявката за WebDAV може да има множество под-заявки, като всяко от тях има свой собствен статус и отговор. Състоянието 207 показва, че тялото на отговора ще включва XML документ, в който са подробно описани състоянието и отговорите на всяка под-заявка.

HTTP 208 Вече отчетено

Друг код за състояние само за WebDAV. Това означава, че членовете на DAV обвързване вече са изброени в предишен отговор на текущата заявка и не се включват отново.

HTTP 226 IM Използва се

Сървърът е изпълнил заявка за ресурса и отговорът е представяне на резултата от една или повече манипулации на инстанция, приложени към текущия екземпляр.

HTTP статус код 3xx – пренасочване

Всеки път, когато се откажете от нещо, трябва да го замените с нещо.

—Ло Холц

Статусите в клас 3xx се изпращат, когато са необходими допълнителни действия от страна на клиента, за да се изпълни заявката. Това най-често се използва при пренасочване на един URL адрес към друг, макар и не винаги.

В случай на GET заявки, браузърът обикновено изпълнява втората заявка без никакво въвеждане или допълнително взаимодействие от страна на потребителя. В други случаи е необходима допълнителна намеса на потребителя.

За да избегнат безкрайните контури за пренасочване, браузърите обикновено не следват повече от пет последователни пренасочвания на една и съща заявка.

HTTP 300 множество възможности

Състоянието 300 се връща от браузърите, когато заявката води до множество опции за ресурса. На теория това може да бъде полезно за представяне на различни опции за файлов формат, различни медийни презентации на едно и също съдържание или дори разграничение на думите.

Състоянието 300 Множествен избор има голям потенциал, но не се използва често.

HTTP 301 се премества постоянно

Това състояние показва, че ресурсът е променил URL адреса за постоянно.

Търсачките актуализират своя индекс въз основа на това, като обикновено присвояват всяко класиране от първоначалния до новия URL адрес.

Браузърите и други видове клиенти често кешират новия URL адрес и автоматично следват URL адреса за пренасочване, без директно да проверяват оригинала за следващи заявки, дори ако оригиналният URL адрес се предоставя ръчно. Запазените отметки също обикновено се актуализират.

Като цяло, ако настройвате пренасочвания поради промяна в името на домейна на структурата на URL, трябва да използвате 301: Преместени постоянно пренасочвания.

Те могат да бъдат настроени във .htaccess или httpd.conf файл на вашия сървър или често във вашата система за управление на съдържанието. (Например, има няколко приставки за WordPress за управление на пренасочвания на 301.)

Когато уебсайтът е препроектиран и структура на URL адреса е променена, е много важно да настроите пренасочване 301 за всеки URL адрес от оригиналния сайт. Ако не го направите, това ще доведе до скъсани връзки и разочаровани посетители.

Намерен HTTP 302

Кодът на състоянието 302 обикновено се използва за временни пренасочвания. Промишлената практика с 301 пренасочвания се различава от оригиналната спецификация и спецификацията се е развила, за да отговори на индустриалната практика.

Първоначално в спецификацията е посочено, че състояние 302 трябва да накара браузъра да направи втора, идентична заявка на новия URL адрес. Въпреки това много уеб браузъри от първо поколение го реализираха по такъв начин, че POST заявките бяха пренаписани като GET заявки.

За да се опита да изясни ситуацията, актуализираната спецификация HTTP / 1.1 добави два допълнителни кода на състоянието, 303 и 307.

302 Found трябваше да имитира поведението „преминаване към GET“, което беше приложено, докато 307 временното пренасочване беше предназначено да замени първоначалното 302 очаквано поведение.

Въпреки това повечето сървъри и уеб рамки просто продължават да използват 302 за обратна съвместимост с браузъри, които не прилагат по-новите стандарти.

По-късно HTTP спецификации, придобити на стандартната практика, позволяват на браузърите да пренаписват POST заявки към GET заявки.

Следствието на всичко това е, че ако използвате пренасочване 302 на URL адрес, който е трябвало да приеме POST данни, тези данни вероятно няма да бъдат включени във втората заявка.

По тази причина 302 трябва да се използва само за URL адреси, които приемат POST данни (уеб формуляри), ако сървърът действително може да приеме предоставените данни на първоначалния URL адрес и да използва пренасочването за доставяне на страница, след като данните са приети..

Всичко това на практика прави 303 излишни.

По принцип не трябва да се използва пренасочване 302

HTTP 303 Вижте Други

На практика това е идентично със статус 302. Това означава, че отговорът или ресурсът могат да бъдат намерени на друг URL адрес чрез метода GET. Когато бъде получен в отговор на POST заявка, браузърът трябва да приеме, че данните са получени.

HTTP 304 не е модифициран

Уеб браузърите могат да изпращат заявка с заглавка, която пита дали ресурсът е променен от определени данни и време. Това се прави, ако браузърът вече е изтеглил ресурса преди това и го е запазил.

Ако е променен от това време, сървърът ще отговори с ресурса и със статут на 200 успеха.

Ако обаче ресурсът не е променен, сървърът ще изпрати състоянието 304 Not Modified и също не изпрати ресурса. След това браузърът трябва да обслужва запазената версия на ресурса, тъй като той не е променен.

HTTP 305 Използвайте прокси

Исканият ресурс е достъпен само чрез прокси. Адресът на пълномощника е посочен в отговора. Очаква се уеб браузърът да опита отново чрез прокси сървъра. Не всички клиенти прилагат това според стандарта, поради съображения за сигурност.

HTTP 306 Switch Proxy

Състоянието 306 първоначално означаваше „Следващите заявки трябва да използват указания прокси.“ Вече не се използва.

HTTP 307 временно пренасочване

Този статус е създаден, за да възпроизведе първоначалното намерение на състоянието 302 (вижте по-горе).

Състоянието 307: Временно пренасочване означава, че този път заявката трябва да бъде повторена с друг URL адрес, но в бъдеще заявките все пак трябва да използват оригиналния URL адрес.

За разлика от това как 302 е реализиран исторически от клиентите, методът на заявка не трябва да се променя при изпращане на втората заявка. Например, POST заявка трябва да се повтори, като се използва друга POST заявка и с включени всички оригинални POST данни.

HTTP 308 постоянен пренасочване

Текущата заявка трябва да бъде повторена с друг URL адрес и всички бъдещи заявки също трябва да бъдат изпратени до този URL адрес.

Подобно на 307 и 302, този статус дублира функционалността, посочена в оригиналната спецификация на 301. Въпреки това, с 308, обаче, втората заявка трябва да бъде идентична с първоначалната заявка – като се използва същия метод и съдържа същите данни.

HTTP 308 Възобновете непълното

Този код на състоянието е създаден и се използва от Google. Той е част от предложението за възобновяеми заявки на HTTP и се използва за възобновяване на прекъснати PUT или POST заявки.

HTTP статус код 4xx – клиентска грешка

Всеки може да прави грешки, но само идиотът продължава да греши.

– Марк Тулий Цицерон

От петте класа кодове на състоянието на HTTP, само два от тях са наистина „кодове на грешки“, класовете 4xx и 5xx.

Серията 4xx грешки в HTTP е предназначена да се използва, когато изглежда, че грешката идва от клиента – тоест има нещо нередно в заявката.

Заедно със състоянието на грешката и друга информация за заглавката, сървърите често предоставят пълен отговор (наречен „субект“ вместо „ресурс“, но в противен случай същият), който се очаква да бъде показан на потребителя.

Това има за цел да предостави на потребителя начин да поправи каквато и да е грешка на клиента. Най-често наблюдаваната форма на тези образувания е страницата 404, разгледана по-долу.

HTTP 400 Лоша заявка

Това е общ отговор на заявка с някакъв проблем. Проблемът може да бъде неправилно форматиран синтаксис, невалидно форматиране или измамно маршрутизиране на заявката. Сървърите често предоставят допълнителна информация за това какво конкретно се обърка в заявката.

HTTP 401 неоторизиран

Използва се, когато ресурсът е ограничен до определени удостоверени потребители. Състоянието означава, че не е имало удостоверяване или че автентификацията е неуспешна. Според стандарта, отговор с този код трябва да включва средство за автентификация.

HTTP 402 Необходимо плащане

Не се използва често, тъй като спецификацията не предоставя достатъчно информация за текуща реализация (тя е посочена и запазена за бъдеща употреба, но пълна спецификация не е приета).

Намерението е този код да се използва като част от някакъв вид цифрови пари в брой или система за микроплащане.

YouTube използва този статус, ако получи твърде много заявки от един IP адрес. Отговорът изисква CAPTCHA, за да се провери, че потребителят е човек.

HTTP 403 Забранено

Подобно на 401, това означава, че заявката е била валидна, но сървърът няма да отговори на нея, тъй като потребителят няма разрешение за преглед на ресурса. За разлика от грешка 401: Неоторизирана грешка, автентифицирането няма да има никаква разлика.

HTTP 404 не е намерен

Това е най-често наблюдаваната грешка в клас 4xx и може би най-често забелязваният HTTP статус за средния потребител.

404 се връща, ако заявката е валидна, но заявеният ресурс просто не може да бъде намерен на сървъра.

Повечето уеб рамки дават възможност на администратора на уебсайта да създаде „Страница 404“. Това е страница, която потребителят вижда, когато възникне грешка 404.

Обикновено това информира потребителя за проблема, извинява се за неудобството и предоставя алтернативни начини за намиране на съдържанието, което потребителят търси, като например търсене.

Някои уебсайтове ще разгледат всички ключови думи в URL адреса на заявката и ще се опитат да определят каква страница или ресурс може да е търсил потребителят и да предоставят една или повече опции за алтернативни страници.

Въпреки че 4xx грешките са технически „Клиентски грешки“, грешката 404 често е резултат от мъртви връзки – URL адреси, които преди са имали съдържание, но които сега са се променили.

Поради тази причина, предоставянето на страница 404 може да бъде малко неудобно за уебсайтовете, тъй като често означава невъзможност за осигуряване на правилно пренасочване на URL адреси. Импликацията не е „объркахте заявката си“, а по-скоро „загубихме това, което търсите“.

Поради това е много често уебсайтовете да превръщат своите 404 страници в място за хумор.

HTTP 405 Методът не е разрешен

Използва се, когато заявката е добре оформена и ресурсът, за който тя иска, съществува, но методът на заявка (като GET или POST) не е подходящ за ресурса.

Например, URL адрес, който е получил данни от формуляр, трябва да се получи с POST заявка. Заявката GET може да доведе до отговор 405: Методът не е разрешен. Използването на PUT на ресурс само за четене също може да предизвика такъв отговор.

HTTP 406 Не е приемливо

Заявките могат и често да определят типа съдържание, което търсят, като използват MIME типове.

Ако заявеният ресурс е от тип, който не съвпада с типа (ите), посочени в заглавката Accept на заявката, сървърът ще върне грешката 406: Не е допустима.

Изисква се удостоверяване на прокси HTTP 407

Преди да му бъде предоставен достъп до заявения ресурс, клиентът първо трябва да се удостовери с прокси сървъра, посочен в отговора.

HTTP 408 Заявка за изчакване

Тази грешка се случва, когато сървърът изчака, докато чака заявката.

От спецификацията:

Клиентът не е изпратил заявка в рамките на времето, когато сървърът е готов да изчака. Клиентът МОЖЕ да повтори заявката без промени по-късно.

HTTP 409 конфликт

Указва, че заявката не може да бъде обработена, защото противоречи на себе си. Това може да се случи например в случай на множество актуализации, които причиняват редактиране на конфликти помежду си.

HTTP 410 изчезна

Тази грешка е подобна на грешката 404, но има за цел да покаже, че исканият ресурс е бил умишлено премахнат и вече няма да е достъпен при нито един URL адрес.

Клиентите трябва да реагират на този отговор чрез пречистване на ресурса – отметките трябва да бъдат изтрити, а търсачките да премахнат ресурса от своите индекси.

Повечето случаи на използване не изискват това и 404 обикновено е по-подходяща грешка.

HTTP 411 Необходима дължина

Заявеният ресурс изисква заявките да посочват тяхната дължина и заявката не го прави.

HTTP 412 Предварителното условие не бе успешно

Заявителят постави предпоставки или изисквания в заглавката на заявката и сървърът не може да изпълни едно или повече от тези изисквания.

HTTP 413 Заявка за субект твърде голяма

Заявката е по-голяма, отколкото сървърът може да обработи.

HTTP 414 Заявка-URI Твърде дълго

Предоставеният URI (URL) беше твърде дълъг, за да може сървърът да обработва.

Това често е причина, когато в URL адреса се предава неподходящо количество данни като низ от заявки в GET заявка. Обичайното средство за защита е да преобразувате заявката в POST и да поставите данните в тялото на заявката.

HTTP 415 Неподдържан тип носител

Това обикновено се използва за качване на файлове, когато запитващото образувание (файлът, който се качва) е от тип, който не се поддържа от сървъра.

HTTP 416 Изисквания диапазон не е удовлетворителен

Това се връща, когато заявката изисква част от файла, като се използва заглавката на обхвата, но заявената част не съществува. Например, ако заявката изисква част от файла, която е извън края на файла.

HTTP 417 Очакването не бе успешно

Това състояние се връща от сървър, ако не може да отговори на очакванията, зададени от заглавката на очакванията в заявката.

Заглавката на очакванията се използва най-често, за да поиска сървъра за състояние 100 Continue.

HTTP 418 Аз съм чайник

Този код за грешка се връща от чайници, свързани с интернет, в случай че им бъде изпратена заявка за кафе.

Време за изчакване за удостоверяване на HTTP 419

Това всъщност не е част от стандарта HHTP, но някои клиенти и сървъри го използват. Връща се, когато заявка, която изисква удостоверен потребител, е изпратена от заявителя, чието удостоверяване е изтекло.

HTTP 420 метод за отказ (пролетна рамка)

Не е част от HTTP стандарта, но дефиниран от Spring в тяхната уеб рамка, за използване, когато метод не е успешен. Той е остарял.

HTTP 420 Увеличете спокойствието си (Twitter)

Не е част от стандарта HTTP, но представен от Twitter. Това се използва от Версия 1 на техния API, когато исканията от конкретен клиент бяха ограничени.

По-стандартният статус за подобна ситуация е 429: Твърде много заявки.

HTTP 421 неправилна заявка

Този статус беше въведен в HTTP / 2. Използва се, когато заявката е насочена към сървър, който в момента не може да генерира отговор.

HTTP 422 необработваем субект

Това е свързано с разширението WedDAV. Той се връща, когато семантичните грешки правят заявката неприложима.

HTTP 423 заключен

Използва се с WedDAV. Това означава, че исканият ресурс е заключен.

HTTP 424 Неуспешна зависимост

Използва се с WebDav. Заявката не бе успешна, тъй като предишна заявка, от която зависи настоящата заявка, не бе успешна.

HTTP 426 Необходима надстройка

Клиентът трябва да премине към различен протокол, както е посочено в заглавката на надстройката.

HTTP 428 Необходимо условие

Това се използва, когато сървърът изисква заявката да е условна.

Например сървърът може да изисква заявката да съдържа условие, че заявката трябва да бъде обработена само ако ресурсът не е актуализиран от определена дата и час. Ако не е посочено условие, заявката се проваля и това състояние се връща.

Според спецификацията, този статус е имал за цел да предотврати проблема “загубена актуализация”, при който клиентът връща състоянието на ресурса, променя го и го връща обратно към сървъра, когато междувременно трета страна е променила състоянието на сървъра , което води до конфликт. “

HTTP 429 Твърде много заявки

Клиентът (обикновено както е дефиниран от IP адрес) е изпратил твърде много заявки в рамките на определен период.

HTTP 431 Поискайте полета на заглавките твърде големи

Това се връща, когато едно поле заглавие, или всички заедно, е твърде голямо, за да може сървърът да обработва.

Време за изчакване за влизане в HTTP 440 (Microsoft)

Не е част от стандарта, но се използва от Microsoft. Указва, че сесията е изтекла.

HTTP 444 Без отговор (Nginx)

Не е част от стандарта. Всъщност не е състоянието на отговор, както се използва.

Това беше въведено от Nginx за техните сървърни регистрационни файлове, за да посочи кога сървърът просто не изпрати отговор и затвори връзката, обикновено в случай на предполагаема атака на зловреден софтуер.

Повторен опит с HTTP 449 (Microsoft)

Не е част от стандарта, но се използва от Microsoft.

Искането трябва да бъде повторено след изпълнение на действието, описано в отговора.

HTTP 450 блокиран от родителския контрол на Windows (Microsoft)

Не е част от стандарта, но се използва от Microsoft.

Тази грешка се получава, когато родителският контрол на Windows е включен и блокира достъпа до дадената уеб страница. Грешката произлиза от приложението WPC, а не от сървъра.

HTTP 451 не е налице за правни причини (чернова)

Този статус все още не е част от стандарта, но е наличен под формата на чернова.

Предназначението е за използване, когато ресурс не може да бъде предоставен поради цензура или други правни причини. Кодовият номер е препратка към книгата Farenheit 451.

Пренасочване на HTTP 451 (Microsoft)

Не е част от стандарта, но се използва от Microsoft. Възниква в Exchange ActiveSync, ако има или по-ефективен сървър за използване или сървърът не може да получи достъп до пощенската кутия на потребителите.

HTTP 494 Изисквайте заглавието твърде голямо (Nginx)

Не е част от стандарта, но се използва от Nginx. Сега остарял.

Това имаше същото значение като 431, но беше въведено преди този статус да е част от HTTP стандарта.

HTTP 495 Cert Грешка (Nginx)

Не е част от стандарта. Всъщност не е състоянието на отговорите, както се използва, но се появява в регистрационните файлове на Nginx, когато възникне грешка в сертификата на SSL клиент.

HTTP 496 Без сертификат (Nginx)

Не е част от стандарта. Всъщност не е състоянието на отговорите, както се използва, но се появява в регистрационните файлове на Nginx, когато клиентът не е предоставил сертификат.

HTTP 497 HTTP към HTTPS (Nginx)

Не е част от стандарта. Всъщност не е състоянието на отговорите, както е използвано, но се появява в регистрационните файлове на Nginx, когато обикновени HTTP заявки се изпращат до HTTPS порта.

Изтекъл / невалиден HTTP 498 токен (Esri)

Върнати от ArcGIS за сървър. Код от 498 показва изтекъл или по друг начин невалиден маркер.

Затворена заявка на HTTP 499 (Nginx)

Не е част от стандарта. Всъщност не е състоянието на отговора, както е използвано, но се появява в регистрационните файлове на Nginx, когато връзката е затворена от клиента, докато сървърът все още обработва заявката си, като сървърът не може да изпрати обратно код на състоянието.

HTTP 499 Токен (Esri)

Върнати от ArcGIS за сървър. Код от 499 показва, че се изисква токен (ако не е изпратен маркер).

HTTP Status Code 5xx – Грешка в сървъра

Наистина съм изумен, когато смятам колко слаб е умът ми и колко съм склонен към грешки.

– Рене Декарт

Заедно с серията 4xx, клас 5xx от HTTP кодове за състоянието са кодове за грешки, издадени, когато нещо се обърка. Кодовете за грешки 5xx са кодове за грешки в сървъра, което означава, че се връщат, когато проблемът е на сървъра, а не с клиента.

Когато е възможно, сървърът трябва да върне обект за отговор, който описва грешката на клиента. Потребителските агенти (уеб браузъри) трябва да показват тази информация на потребителя.

HTTP 500 вътрешна сървърна грешка

Това е най-общата сървърна грешка и се издава от уеб сървъри, когато нещо неопределено се обърка.

По принцип всяка промяна в конфигурация на уебсайт или сървър трябва да бъде последвана от задълбочено тестване, за да се гарантира, че 500: Вътрешна грешка в сървъра не е произведена.

Когато се генерира грешка 500, разглеждането на регистрационните файлове на сървъра често може да помогне да се определи откъде идва грешката. Тя често може да бъде толкова проста, колкото печатни грешки във файла .htaccess.

HTTP 501 не се прилага

Това се връща, когато методът на заявка HTTP (като PUT или DELETE), методът на API в някои случаи, все още не е приложен. Това се използва за API на уеб услуги. Обикновено последицата от грешка 501 е, че методът на заявка е планиран за бъдещо внедряване.

HTTP 502 Bad Gateway

Това се случва, когато сървърът действа като прокси или шлюз и получи невалиден отговор от възходящия сървър.

HTTP 503 Услугата не е налична

Понастоящем сървърът не е наличен. Например, защото е претоварен или свален за поддръжка.

Последицата от грешка 503 е, че прекъсването е временно.

Време за изчакване на шлюз HTTP 504

Тази грешка се връща, когато сървърът действа като прокси или шлюз и не получава отговор от възходящия сървър в рамките на разпределеното време.

HTTP 505 HTTP версия не се поддържа

Тази грешка означава, че сървърът не поддържа версията на HTTP протокол, използвана в заявката.

HTTP 506 Вариант също води преговори

За да разберете грешката 506, трябва да разберете прозрачно съгласуване на съдържанието.

При договаряне на съдържание, един URL адрес може да доставя един и същ ресурс или информация в множество формати. Например, същото изображение може да бъде кодирано като JPEG и като GIF.

Грешката 506 възниква, когато това преговаряне на съдържание причинява цикъл. Например: Исканият ресурс A има две вариации – B и C. И двете имат A като вариант.

За да кажем това на по-технически език, спецификацията описва грешката 506 с:

Прозрачното съгласуване на съдържанието за заявката води до кръгова справка.

HTTP 507 недостатъчно съхранение (WebDAV; RFC 4918)

Този статус се използва протокола WebDAV. Той се връща, когато сървърът не е в състояние да съхранява представителството, необходимо за завършване на заявката.

Открит HTTP 508 цикъл

Сървърът срещна безкраен цикъл, докато се опитваше да обслужва искания ресурс.

Превишен лимит на честотна лента HTTP 509 (Apache)

Не е част от HTTP стандарта, но е въведен и използван от Apache. Той се издава, когато са надвишени границите на пропускателната способност на сървърите.

HTTP 510 не е разширен

Тази грешка означава, че са необходими допълнителни разширения на заявката, за да може сървърът да го изпълни.

HTTP 511 Необходима мрежа удостоверяване

Грешката 511 се връща, когато клиентът трябва да се удостоверява, за да получи достъп до мрежата.

Този статус е предназначен за използване при прихващане на прокси сървъри, използвани за контрол на достъпа до мрежата – тоест „Портални задържани портали“, използвани за изискване за влизане или споразумение за Условия за обслужване, преди да се предостави достъп до интернет чрез WiFi портал.

(Ако някога сте се опитвали да се свържете онлайн на летище или хотел, вероятно сте се сблъскали с грешка 511.)

HTTP 520 Неизвестна грешка

Този код за грешка не е част от HTTP стандарта, но се използва от няколко големи доставчици на сървърна инфраструктура като услуга като CloudFlare. Той се използва като обща грешка „прихващане“ за неидентифицирани проблеми, в резултат на което заявката не се попълва.

Грешка в тайм-аут за четене на HTTP 598 (Microsoft)

Този код за грешка не е част от стандарта HTTP, но се използва от HTTP прокси сървъри на Microsoft, за да сигнализира за изчакване на мрежата за четене зад прокси на клиент пред прокси сървъра.

Грешка в изчакване на мрежовото свързване на HTTP 599 (Microsoft)

Този код за грешка не е част от стандарта HTTP, но се използва от HTTP прокси сървъри на Microsoft, за да сигнализира за изчакване на мрежова връзка зад прокси сървъра към клиент пред прокси сървъра.

ресурси

  • IANA: уебсайтът на органа за присъединяване към интернет.
  • Регистър на кода на HTTP статус: официалната страница на IANA с връзки към RFC за всеки код.

Допълнителна информация

Имаме още ръководства, ръководства и инфографика, свързани с уеб разработката:

  • Надолу ли е? Страници със статут на 50 най-добри доставчици на хостинг услуги: дори най-добрите сървъри от време на време намаляват Тази статия предоставя списък на страниците със статут на 50 от най-добрите хостинг компании.
  • Мрежово програмиране с интернет сокети: ако искате да научите твърди ядрени мрежи, това е статията, за да започнете.
  • Най-добрият списък с инструменти за уеб администратори A-Z: от кодиране до хостинг до маркетинг, в тази статия има всичко.

Последно ръководство за уеб хостинг

Вижте нашето крайно ръководство за уеб хостинг. Той ще ви обясни всичко, което трябва да знаете, за да направите информиран избор.

Последно ръководство за уеб хостинг
Последно ръководство за уеб хостинг

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map