Що означає повідомлення коду стану HTTP?

Кожен користувач Інтернету і кожен веб-майстер хоч раз у житті бачили замість веб-сторінки статус HTTP-коду. Ці коди, по суті, є повідомленнями про поточний стан сервера і можуть багато розповісти про ситуацію з веб-сторінкою або самим сервером. Тому, якщо вебмастер зрозуміє сенс коду відповіді на веб-запит, він зможе точно діагностувати корінь проблеми і без проблем виправити її на сервері.

Веб-майстрам дуже важливо також розуміти, як повідомлення з кодами веб-статусу впливають на користувачів та як вирішувати ці проблеми якнайшвидше. Зокрема, веб-майстрам дуже важливо розуміти значення кожного коду, що відображається, і те, що він означає для клієнтської сторони (користувачів), коли вони стикаються з такими проблемами, незалежно від того, де знаходиться корінь проблеми.

Що таке код відповіді

Коди веб-відповідей, також відомі як коди HTTP, коди стану і т. д., є основною формою відповіді на запити, надіслані клієнтом (зазвичай користувачем веб-сайту) на сервер. Це повідомлення з тризначними номерами, призначені передачі інформації про результат запиту, чи, по суті, звіти про стан. Коди стану запитів повідомляють клієнта або веб-майстра, що проводить діагностику, про поточний стан ресурсу і можливі причини виникаючих проблем, якщо такі є.

Ці службові повідомлення розділені на п'ять окремих груп, які представляють категорії значень кодів стану та серйозності стану веб-ресурсу. Таким чином, ці коди дозволяють веб-майстру визначити проблему та знайти спосіб її виправити.Таким чином, ці коди, по суті, дозволяють ефективно вирішувати різні сценарії експлуатації та розробки веб-ресурсів, таких як сайти, сервери та програми.

Якщо ви працюєте веб-майстром і знаєте, що описує той чи інший код веб-статусу, ви зможете визначити, що сталося на сервері, як була неправильно оброблена внутрішня структура чи код, чи яка ситуація сталася під час міграції чи оновлювати. Все буде залежати від цифр, згаданих у звіті про коди помилок сервера, і ви зможете легко вирішити ситуацію.

Наприклад, відповідь з кодом 404 або повідомлення "Не знайдено"; Повідомлення про помилку показує, що запитуваний об'єкт або URL-адреса не існує у файловій системі сервера. Це повідомлення зазвичай з'являється, коли чогось на сервері не вистачає або його місце у структурі папок було змінено. Така ситуація часто трапляється із сайтом, який щойно завершив міграцію з хоста на хост.

З іншого боку, часто зустрічається інший статус коду: 502 або Bad Gateway. тут описується ситуація, коли щось не так з мережевим підключенням. Зазвичай цей код відповіді сервера повідомляє клієнту (користувачу) та веб-майстру, що сервер та веб-сайт оновлюються, переносяться, перебувають на обслуговуванні або зазнають серйозного мережного навантаження.

Класи кодів стану відповіді

Оскільки існує широкий спектр статусів на стороні сервера, існує стільки ж звітів із кодами стану сервера, які описують кожен із цих статусів у списку. Ці звіти мають суто діагностичний характер, і дуже важливо розуміти, як вони працюють, що описують і як вони можуть допомогти у пошуку причин різних проблем.

Список кодів стану починається зі 100 і закінчується на 599, тому без системного підходу може бути дуже складно розрізнити їх усі. Тому всі коди згруповані в п'ять категорій за типами статусів кодів, що містять 100 кодів у кожній.

Перша категорія від 100 до 199 відноситься до нормальної роботи сервера або незначних проблем, що не впливають на нормальну роботу. Друга група (від 200 до 299) стосується незначних проблем, що впливають на роботу сервера, зазвичай це невеликі помилки, уповільнення або затримки.

Третя категорія вже серйозна — звіти з номерами від 300 до 399 стосуються недоречного чи відсутнього контенту чи змін у внутрішній структурі папок сервера. Четвертий список помилок коду стану від 400 до 499 відноситься до проблем на стороні користувача або клієнта та мережних проблем. І остання, але не менш важлива п'ята група відноситься до серйозних проблем з сервером і варіюється від 500 до 599.

Значення коду стану 1xx – інформаційна відповідь

Ця категорія має виключно інформаційний характер, як і передбачає її назву. Повідомлення з числами в цьому діапазоні зазвичай означають, що надсилання відповіді на дію користувача йде як слід, але з тих чи інших причин виникають затримки. Зазвичай із сервером чи самим ресурсом немає нічого серйозного, а скоріше майже непомітні невеликі проблеми на кшталт невеликих підгальмовувань при завантаженні контенту тощо.

Часто користувачі їх просто не бачать, тому що вони з'являються у фоновому режимі (в логах) і через деякий час все завершується нормально. Дивно, але в цей діапазон не входять звіти про стан, що описують нормальну роботу сайту, вони включені лише до другої групи.

Код стану 2xx означає успішну обробку запиту

Це список, який включає коди успішного завершення. Ця група з'являється, коли обробка дії клієнта (користувача) пройшла успішно, але виникли помилки чи затримки, які вплинули на загальну продуктивність. Зазвичай такі повідомлення звіту з'являються в журналах, коли вміст має занадто великий розмір, відсутній, пошкоджений або переміщений під час обробки. Для веб-майстрів такі коди є ознакою проблемного контенту, що впливає на продуктивність ресурсу та зручність використання. В ідеалі ці помилки необхідно відстежувати, щоб зміст сайту залишався в хорошому стані і мав оптимальний розмір, щоб не порушувати зручність роботи з веб-ресурсом.

Код стану 3xx означає перенаправлення на стороні сервера

До цієї категорії належать повідомлення-звіти, які повідомляють користувача та веб-майстра про зміни у внутрішній структурі сервера та подальшому перенаправленні, успішному чи ні. Поява звіту з однією з цифр у цій галузі показує, що запитаний ресурс був переміщений усередині файлової системи сервера, повністю вилучений або іншим чином недоступний клієнту (користувачу). Часто користувач бачить такий звіт, коли файлову структуру веб-ресурсу було оновлено або повністю змінено, у тому числі при міграції з хоста на хост без належного налаштування.

Значення коду стану 4xx – помилки та помилки на стороні користувача

Група повідомлень, що вказують на проблеми з діями користувача, неправильні вказівки або проблеми з мережею. Фактично це найбільш поширена група, з якою стикаються користувачі.Найчастіше зустрічається код 400 «Bad Request», який вказує на неправильно вказану URL-адресу або розташування файлу. До цієї групи також входять випадки, коли користувач намагається отримати доступ до частин ресурсу, які потребують додаткових прав або дозволів, включаючи області, заборонені для будь-кого, крім веб-майстрів або адміністраторів. Ця група також включає проблеми мережі на стороні клієнта, включаючи тайм-аут (код 408), викликаний проблемами між клієнтом (користувачем) і сервером.

Значення коду стану 5xx — помилки та проблеми на стороні сервера

Повідомлення про стан у цій групі представляють проблеми на стороні сервера та інформують користувачів та веб-майстрів про те, що сервер не може обробляти дії через внутрішні чи зовнішні проблеми. Зазвичай звіти про помилки цієї групи вказують на серйозні проблеми з апаратним або програмним забезпеченням сервера, а також проблеми із загальною стабільністю та роботою сервера. Крім того, ці коди інформують веб-майстрів про різні шкідливі дії, проблеми з мережею, проблеми з кодом веб-ресурсів і неправильні конфігурації програмного забезпечення. В результаті ці оповіщення можуть допомогти веб-адміністраторам діагностувати та усувати широкий спектр проблем: від браку пам'яті сервера або перевантаження пропускної здатності до DDoS-атак та нестабільних мережних вузлів.

Як отримати повідомлення з кодом відповіді

Існує три очевидні способи отримати повідомлення з кодом стану запиту. Перший — отримати звіт прямо з веб-ресурсу, спробувавши отримати доступ до нього через браузер або через програму. Іноді його можна отримати замість відвідування веб-ресурсу.Другий метод, якщо ви веб-майстер з повними правами доступу, це пошук по журналах на випадок, якщо щось сталося. Але цей спосіб також ненадійний, якщо вам потрібен точний метод пошуку коду веб-відповіді для діагностики. Тому що він не показуватиме поточний статус веб-сайту, якщо ви не перевірите його вручну.

Оскільки перший і другий методи вважаються ненадійними, існує третій спосіб отримати код стану помилки - постійний моніторинг веб-сайту за допомогою відповідних інструментів, які призначені для перевірки помилок HTTP-відповіді. Наприклад, ви можете використовувати HostTracker для отримання всіх типів повідомлень про стан коду вручну або автоматично. Цей набір інструментів для моніторингу веб-сайтів містить інструменти перевірки, які обробляють запити HTTP до веб-ресурсу і отримують звіт у вигляді коду помилки. Він простий у використанні і доступний навіть новачкам, але дуже допомагає усунути різні проблеми, пов'язані з тими кодами, які перевірки отримують з сервера.

Часті питання

Що таке код статусу

По суті, код веб-відповіді або код стану – це діагностичний звіт із сервера. Він повідомляє клієнту (пристрою користувача або діагностичному інструменту веб-майстра) про стан веб-ресурсу, переважно сервера. Говорячи технічною мовою це код, який повідомляє про відповідь сервера на дії клієнта. Він працює за протоколом HTTP і містить певну кількість у діапазоні від 100 до 599, що означає стан обробки запиту. А якщо під час обробки виникнуть проблеми, цей код вкаже на корінь проблеми і допоможе її вирішити.

Директор з комунікацій та технологій компанії HostTracker.Олексій є частиною команди із перших днів існування компанії. Його робота зосереджена на складанні бізнес-звітів, аналізі статистики баз даних та системному адмініструванні. Олексій також відповідає за комунікації з командою розробників та клієнтами.

S3.Blog

У першому рядку відповіді HTTP-сервера міститься інформація про те, був запит клієнта успішним чи ні, а також дані про причини успішного чи неуспішного завершення запиту. Ця інформація позначається трирозрядним кодом відповіді сервера (іноді його називають кодом стану) та супроводжується описовим повідомленням.

Коди станів зазвичай генеруються Web-серверами, але іноді це можуть робити і CGI-сценарії, CGI-сценарії генерують власні заголовки замість тих, які має видавати сервер. Коди станів групуються таким чином:

У HTTP у кожному діапазоні визначено лише кілька кодів, хоча сервера за необхідності можуть визначатися власні коди. Клієнт при отриманні коду, який він не може розпізнати, інтерпретує його відповідно до діапазону, до якого цей код належить. Коди в діапазонах 100-199, 200-299 та 300-399 більшість Web-браузерів обробляють без сповіщення користувача, а деякі коди помилок з діапазонів 400-499 та 500-599 відображаються для користувача (наприклад, 404 Not Found).

Інформаційні відповіді

Відповіді в діапазоні 100-199 – інформаційні; вони показують, що запит клієнта прийнято та обробляється.

• 100 Continue
  Початкова частина запиту прийнята і клієнт може продовжувати передачу запиту.
  
• 101 Switching Protocols
  Сервер виконує вимогу клієнта та перемикає протоколи відповідно до вказівки, даної в полі заголовка Upgrade.

Успішні запити клієнта

Відповіді в діапазоні 200-299 означають, що запит клієнта успішно оброблений.

• 200 OK
  Запит клієнта успішно оброблений, і відповідь сервера містить затребувані дані.
  
• 201 Created
  Цей код стану використовується у разі створення нового URI. Разом з цим кодом результату сервер видає заголовок Location (див. розділ 19), який містить інформацію про те, куди були розміщені нові дані.
  
• 202 Accepted
  Запит прийнято, але обробляється не відразу. У тілі вмісту відповіді сервера може бути подана додаткова інформація про дану транзакцію. Гарантії того, що сервер зрештою задовольнить допустимим.
  
• 203 Non-Authoritative Information
  Інформація в заголовку вмісту взята з локальної копії або третьої сторони, а не з вихідного сервера.
  
• 204 No Content
  Відповідь містить код стану та заголовок, але тіло вмісту відсутнє. Під час отримання цієї відповіді браузер не повинен оновлювати свій документ. Обробник чутливих областей зображень може повертати цей код, коли користувач клацає на марних або порожніх ділянках зображення.
  
• 205 Reset Content
  Браузер повинен очистити форму, яка використовується в даній транзакції для додаткових вхідних даних. Корисний для CGI-додатків, які потребують введення даних.
  
• 206 Partial Content
  Сервер повертає лише частину даних затребуваного обсягу. Використовується у відповіді на запит із заголовком Range. Сервер повинен вказати діапазон, включений у відповідь, у заголовку Content-Range.

Переадресація

Код відповіді в діапазоні 300-399 означає, що запит не виконано і клієнту потрібно вжити деяких дій задоволення запиту.

• 300 Multiple Choices
  Затребуваний URI означає більше одного ресурсу. Наприклад, URI може означати документ, перекладений кількома мовами. У тілі вмісту, повернутому сервером, може бути перелік конкретніших даних про те, як вибрати ресурс правильно.
  
• 301 Moved Permanently
  Затребуваний URI вже не використовується сервером і вказана в запиті операція не виконана. Нове розташування потрібного документа вказується в заголовку Location. У всіх наступних запитах цього документа слід зазначати новий URI.
  
• 302 Moved Temporarily
  Потрібний URI перемішаний, але лише тимчасово. Заголовок Location вказує на місцезнаходження. Відразу після отримання цього коду стану клієнт має дозволити запит за допомогою нового URI, але у всіх наступних запитах необхідно користуватися старим URI.
  
• 303 See Other
  Потрібний URI можна знайти по іншому URI (зазначеному в заголовку Location). Його слід вибрати методом GET за цим ресурсом.
  
• 304 Відмінно
  Це код відповіді на заголовок lf-Modified-Since, якщо URI не змінювався із зазначеної дати. Тіло вмісту не надсилається, і клієнт повинен використовувати свою локальну копію.
  
• 305 Use Proxy
  Доступ до затребуваного URI повинен здійснюватись через proxy-сервер, вказаний у заголовку Location.

Неповні запити клієнта

Коди відповідей у ​​діапазоні 400-499 означають, що запит клієнта неповний. Ці коди можуть означати, що від клієнта потрібна додаткова інформація.

• 400 Bad Request
  Це означає, що сервер виявив у запиті клієнта синтаксичну помилку.
  
• 401 Unauthorized
  Цей код результату, що передається із заголовком WWW-Authenticate, показує, що користувач, що послав запит, не має необхідних повноважень і що при повторенні запиту із зазначенням даного URI користувач повинен такі повноваження надати.
  
• 402 Payment Required
  Цей код у HTTP ще не реалізований.
  
• 403 Forbidden
  Запит відхилений через те, що сервер не хоче (або не має можливості) відповісти клієнту.
  
• 404 Not Found
  Документ із зазначеного URI не існує.
  
• 405 Method Not Allowed
  Цей код видається із заголовком Allow і показує, що метод, який використовується клієнтом, для цього URI не підтримується.
  
• 406 Not Acceptable
  Ресурс, вказаний клієнтом за цим URI, існує, але не в тому форматі, який потрібен клієнту. Разом із цим кодом сервер видає заголовки Content-Language, Content-Encoding та Content-Type.
  
• 407 Proxy Authentication Required
  Proxy-сервер повинен санкціонувати запит перед тим, як пересилати його. Використовується із заголовком Proxy-Authenticate.
  
• 408 Request Time-out
  Цей код відповіді означає, що клієнт не передав повний запит протягом деякого проміжку часу (який зазвичай задається в конфігурації сервера) і сервер розриває мережне з'єднання.
  
• 409 Conflict
  Цей запит конфліктує з іншим запитом або конфігурацією сервера. Інформацію про конфлікт слід повернути до інформаційної частини відповіді.
  
• 410 Gone
  Цей код показує, що затребуваний URI більше немає і назавжди видалено із сервера.
  
• 411 Length Required
  Сервер не прийме запит без зазначеного у ньому заголовка Content-Length.
  
• 412 Precondition Failed
  Результат обчислення умови, заданого у запиті одним або декількома заголовками if.. ., є "брехня".
  
• 413 Request Entity Too Large
  Сервер не оброблятиме запит, тому що його тіло занадто велике.
  
• 414 Request-URI Too Long
  Сервер не оброблятиме запит, тому що його URI занадто довгий.
  
• 415 Unsupported Media Type
  Сервер не оброблятиме запит, тому що його тіло має непідтримуваний формат.

Помилки сервера

Коди відповідей у ​​діапазоні 500-599 показують, що сервер зіткнувся з помилкою та, ймовірно, не зможе виконати запит клієнта.

• 500 Internal Server Error
  При обробці запиту на сервері один із його компонентів (наприклад, CGI-програма) видав аварійну відмову або зіткнувся з помилкою конфігурації.
  
• 501 Not Implemented
  Клієнт запросив виконання дії, яку сервер виконати не може.
  
• 502 Bad Gateway
  Сервер (або proxy-сервер) отримав неприпустимі відповіді іншого сервера (або proxy-сервера).
  
• 503 Service Unavailable
  Цей код означає, що ця служба тимчасово недоступна, але в майбутньому доступ до неї буде відновлено. Якщо сервер знає, коли це станеться, може бути видано заголовок Retry-After.
  
• 504 Gateway Time-out
  Ця відповідь схожа на 408 (Request Time-out), за винятком того, що шлюз або уповноважений сервер перевищив ліміт часу.
  
• 505 HTTP Version no supported
  Сервер не підтримує версію протоколу HTTP, використану у запиті.

Коди стану відповіді HTTP

Код стану відповіді HTTP показує, чи певний HTTP запит було успішно виконано. Відповіді згруповані у 5 класів:

1. Інформаційні відповіді ( 100 – 199 )
2. Успішні відповіді ( 200 – 299 )
3. Повідомлення про перенаправлення ( 300 – 399 )
4. Помилки клієнта ( 400 – 499 )
5. Помилки сервера ( 500 – 599 )

Коди стану визначені RFC 9110.

Примітка: Якщо ви отримали код відповіді, якого немає в даному списку, то він не стандартизований, найімовірніше він специфічний для конкретного сервера.

Інформаційні відповіді

Проміжна відповідь, він вказує, що клієнт повинен продовжити запит або ігнорувати відповідь, якщо запит вже завершено.

Цей код надсилається у відповідь на заголовок запиту Upgrade від клієнта та вказує протокол, на який перемикається сервер.

Сервер отримав і обробляє запит, але відповіді поки що немає.

Цей код в першу чергу призначений для використання з заголовком Link , дозволяючи користувача агенту почати попереднє завантаження ресурсів або здійснити попереднє з'єднання до джерела ресурсів, поки сервер готує відповідь.

Успішні відповіді

Запит успішно виконано. Значення результату успіху залежить від методу HTTP:

• GET : Ресурс був отриманий та переданий у тілі повідомлення.
• HEAD : Відповідь містить заголовки, але тіла повідомлення немає.
• PUT або POST : Ресурс, що описує результат дії, надісланий у тілі повідомлення.
• TRACE : Тіло повідомлення містить повідомлення запиту сервера.

Запит виконаний успішно, і в результаті було створено новий ресурс. Зазвичай це відповідь, яка надсилається на запити POST або PUT .

Запит отримано, але ще не опрацьовано. Це "ухильна" відповідь, оскільки в HTTP немає можливості пізніше відправити асинхронну відповідь з результатом обробки запиту. Цей код призначений для випадків, коли запит обробляється іншим процесом або сервером, а також пакетної обробки.

Повернені метадані не повністю збігаються з тими, що доступні на вихідному сервері, а отримані з іншого джерела. Найчастіше це використовується для дзеркал чи резервних копій ресурсів.За винятком таких випадків краще використовувати відповідь 200 OK.

Для цього запиту немає вмісту для надсилання, але заголовки відповіді можуть бути корисними. Агент користувача може використовувати їх для оновлення закешованих заголовків, отриманих раніше для цього ресурсу.

Повідомляє користувача агенту, що необхідно скинути відображення документа, який відправив цей запит.

Цей код відповіді використовується, коли від клієнта надсилається заголовок Range для запиту лише частини ресурсу.

Передає інформацію про кілька ресурсів у випадках, коли можуть бути доречні кілька кодів стану.

Використовується всередині елемента відповіді, щоб уникнути повторного перерахування «прив'язок» та дублювання даних.

Використовується для відповіді на запити GET у тих випадках, коли сервер хоче надіслати лише змінену частину ресурсу (тобто дельту).

Повідомлення про перенаправлення

Запит має більше однієї можливої ​​відповіді. Агент користувача або користувач повинен вибрати один з них. Немає стандартизованого способу вибору однієї з відповідей, але рекомендується використовувати HTML-посилання на можливі варіанти, щоб у користувача була можливість вибору.

URL-адреса запитаного ресурсу була змінена назавжди. Нова URL-адреса вказана у відповіді.

URI запитаного ресурсу був тимчасово змінено. У майбутньому можуть бути внесені подальші зміни до URI. Отже, цей же URI має використовуватися клієнтом у майбутніх запитах.

Клієнту необхідно отримати запрошений ресурс по іншому URI за допомогою запиту GET.

Цей код використовується для цілей кешування. Він повідомляє клієнту, що відповідь не змінено, тому клієнт може продовжувати використовувати кешовану версію відповіді.

Запитана відповідь має бути доступна через проксі. Цей код визначено в попередній версії специфікації HTTP і зараз застарів через проблеми безпеки, пов'язані з внутрішнім налаштуванням проксі-сервера.

Цей код відповіді зарезервовано. Використовувався у попередній версії специфікації HTTP/1.1.

Клієнту необхідно отримати запитаний ресурс за іншим URI тим самим методом, який використовувався у попередньому запиті. Він має ту ж семантику, що і код відповіді 302 Found , за винятком того, що користувальницький агент не повинен змінювати метод: якщо в першому запиті використовувався POST , то POST повинен використовуватися і в другому запиті.

Ресурс тепер знаходиться за іншим URI, вказаним у заголовку відповіді Location . Він має ту саму семантику, що і код відповіді 301 Moved Permanently , за винятком того, що користувач агент не повинен змінювати метод, що використовується: якщо в першому запиті використовувався POST , то POST повинен використовуватися і в другому запиті.

Помилки клієнта

Сервер не може або не оброблятиме запит через щось, що сприймається як помилка клієнта (наприклад, неправильний синтаксис, формат або маршрутизація запиту).

Хоча стандарт HTTP визначає цю відповідь як «неавторизовану», семантично вона означає «неавтентифіковану». Це означає, що клієнт повинен автентифікувати себе, щоб отримати відповідь.

Цей код відповіді зарезервований для використання у майбутньому. Початковою метою створення цього коду було використання його для цифрових платіжних систем, однак він використовується дуже рідко, і стандартної угоди не існує.

Клієнт не має права доступу до контенту, тобто він неавторизований, тому сервер відмовляється надати запитаний ресурс.На відміну від 401 Unauthorized, особистість клієнта відома серверу.

Сервер не може знайти потрібний ресурс. У браузері це означає, що URL-адреса не розпізнана. В API це також може означати, що адреса правильна, але ресурс не існує. Сервер також може надіслати цей код відповіді замість 403 Forbidden, щоб приховати існування ресурсу від неавторизованого клієнта. Це найвідоміший код відповіді через його часту появу в мережі.

Метод запиту відомий серверу, але з підтримується цільовим ресурсом. Наприклад, API може не дозволяти виклик DELETE для видалення ресурсу.

Сервер після виконання узгодження контенту не знайшов вмісту, що відповідає критеріям, заданим користувальницьким агентом.

Цей код відповіді схожий на 401 Unauthorized , але автентифікація повинна виконуватись через проксі-сервер.

Сервер може надіслати цей код відповіді при невикористанні з'єднання навіть без попереднього запиту з боку клієнта. Він означає, що сервер хотів би закрити це з'єднання. Ця відповідь використовується порівняно часто, оскільки деякі браузери (наприклад Chrome, Firefox 27+ або IE9) для прискорення використовують механізми попереднього підключення HTTP. Деякі сервери просто закривають з'єднання, не надсилаючи це повідомлення.

Запит конфліктує із поточним станом сервера.

Запитаний вміст було видалено з сервера, і немає можливості переадресації. Очікується, що клієнти видалять свої кеші та посилання на цей ресурс. Специфікація HTTP передбачає, що цей код відповіді буде використовуватися для обмежених за часом або рекламних послуг. API не повинні вказувати ресурси, які були видалені за допомогою цього коду.

Запит відхилений, тому що сервер вимагає вказати поле заголовка Content-Length , але воно не визначене.

Клієнт вказав у заголовках запиту умови, яким сервер не відповідає.

Розмір об'єкта запиту перевищує обмеження, визначені сервером. Сервер може закрити з'єднання або повернути поле заголовка Retry-After.

Запитаний клієнтом URI занадто довгий, щоб сервер зміг його обробити.

Запит відхилений, тому що медіа формат даних, що запитуються, не підтримується сервером.

Сервер не може коректно обробити запит з урахуванням діапазону, вказаного в полі заголовка Range .

Сервер не може виконати очікування, вказане у полі заголовка запиту Expect .

"Жартівлива" відповідь: сервер відхиляє спробу заварити каву в чайнику.

Сервер не може відповісти. Можливо, сервер не налаштований для комбінації схеми та повноважень, зазначених у URI запиту.

Запит сформований правильно, але його неможливо виконати через семантичні помилки.

Запитуваний ресурс заблокований.

Запит не виконано через проблеми у попередньому запиті.

Клієнт надіслав порцію даних занадто рано, перш ніж сервер встановив безпечне з'єднання.

Сервер відмовляється виконувати запит із використанням поточного протоколу, але може бути готовий зробити це після зміни протоколу на вказану в заголовку відповідь Upgrade .

Сервер вимагає, щоб запит містив умови. Ця відповідь призначена для запобігання проблемі одночасної зміни ресурсу кількома користувачами.

Користувач надіслав надто багато запитів у певний проміжок часу.

Сервер не оброблятиме запит, тому що поля заголовка занадто великі. Запит може бути надіслано повторно після зменшення розміру полів заголовка.

Користувальницький агент запросив ресурс, який не може бути наданий згідно із законом, наприклад веб-сторінку, піддану цензурі з боку уряду.

Помилки сервера

На сервері сталася помилка, внаслідок якої він не може успішно опрацювати запит.

Метод запиту не підтримується сервером і тому його не можна обробити. Методи GET і HEAD повинні завжди підтримуватись сервером і для них не повинен повертатися цей код.

Така відповідь може надіслати сервер, який виступає як шлюз, якщо в процесі обробки запиту він отримав неприпустиму відповідь від цільового сервера.

Сервер не готовий опрацювати запит на даний момент. Найпоширенішими причинами є технічне обслуговування або перевантаження сервера. Разом з такою відповіддю слід надсилати зручну для користувача сторінку з поясненням проблеми, а також заголовок HTTP Retry-After з розрахунковим часом вирішення проблеми. Крім того, корисно надсилати заголовки з інформацією про кешування, оскільки ці тимчасові відповіді зазвичай не слід кешувати.

Така відповідь може надіслати сервер, який виступає як шлюз, якщо в процесі обробки запиту він не може вчасно отримати відповідь цільового сервера.

Версія HTTP, що використовується у запиті, не підтримується сервером.

На сервері відбулася внутрішня помилка конфігурації: обраний у процесі узгодження варіант ресурсу не підходить.

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

Запит не виконано, тому що на сервері було виявлено нескінченний цикл обробки даних.

Для виконання запиту необхідно розширити його.

Клієнту необхідно пройти автентифікацію для отримання доступу до мережі.

Сумісність із браузерами

BCD tables only load in the browser

Дивіться також