Сервер обнаружил в запросе клиента синтаксическую ошибку

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.

Запросы к API

Основная информация о запросах

Запрос — обращение от одного сервиса к другому сервису для получения или отправки информации.

Запросы можно делать к любому стороннему сервису, который их поддерживает. Если вы не можете найти документацию к API в публичном доступе, свяжитесь с поддержкой или разработчиками системы.

• Отправка методом GET →
• Отправка методом POST →
• Удаление последнего сообщения от бота с помощью POST-запроса →
• Удаление последнего сообщения от пользователя с помощью POST-запроса →
• Удаление любого сообщения с помощью POST-запроса →
• Отправка стикера с помощью POST-запроса →
• Отправка запроса в GPT с помощью POST-запроса →
• Обработка ответа — объект →

Ботмама умеет отправлять запросы и принимать ответы только в формате JSON. Если нужная вам система не поддерживает JSON, нужно искать сервис, который изменяет формат запроса, или писать кодом скрипт обработки на сервере. Ещё можно использовать сервисы, которые заменяют интеграцию запросами — например, Zapier.

Объем массива с объектами для отправления запросом может быть не более 1 Мб

Существует множество типов запросов, мы используем только самые распространённые: GET, POST, PUT, PATCH, DELETE.

• GET чаще всего используется как запрос получения информации. В отдельных случаях он может использоваться равнозначно с другими типами. Например, в Telegram можно использовать и GET, и POST для одинаковых запросов.
• POST используется для отправки информации и создания объектов. Этим методом чаще всего создаются заявки, формируются заказы и т.д.
• PUT обновляет информацию об объекте.
• PATCH частично обновляет информацию об объекте.
• DELETE удаляет созданный объект.

Тело в GET запросе можно передавать в строке URL, для остальных запросов — только в специальном поле компонента.

Основная информация об ответах

Ответом на запрос может быть информация об ошибке или об удачном запросе с дополнительными данными или без них.

Об ответах на запросы можно подробно узнать в Википедии.

Чаще всего приходят ответы успеха и ошибок.

Если запрос прошёл успешно, код будет иметь значение, начинающееся на 2:

• 200 OK — успешный запрос.
• 201 Created — в результате успешного выполнения запроса был создан новый ресурс.
• 202 Accepted — запрос был принят на обработку, но она не завершена.

Если запрос не прошёл из-за ошибки параметров запроса, Ботмама считает его успешным. Такие ошибки начинаются на 4:

• 400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку. Этот код используется для любых ошибок такого типа, если разработчик сервиса не вложил другие значения.
• 401 Unauthorized — для доступа к запрашиваемому ресурсу требуется авторизация.
• 403 Forbidden — сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу.
• 404 Not Found — запрашиваемый ресурс не был найдет или не существует.

Если запрос не прошёл из-за ошибки сервера (запрос упал по таймауту, сервер недоступен или тело не удалось распарсить), бот исполняет экран ошибки. В остальных случаях сработает экран успеха. Если ответ пришел валидным со статусом не 200, нужно установить компонент Развилка после запроса и смотреть на статус в теле. Исходя из этого направлять на нужный экран. Ошибки сервера начинаются на 5:

• 500 Internal Server Error — любая внутренняя ошибка сервера. Этот код используется, если разработчик не добавил код для описания данной ошибки.
• 501 Not Implemented — сервер не может обработать запрос. Например, вы используете несуществующий метод.
• 502 Bad Gateway — когда сервер, к которому вы делаете запрос, фактически является буфером между вами и другим сервером, получает некорректный ответ от другого сервера.
• 503 Service Unavailable — сервер временно не может обрабатывать запросы. Такие ошибки возникают, когда сервер выключен, не имеет доступа к Сети или ограничен в доступе.
• 504 Gateway Timeout — когда сервер, к которому вы делаете запрос, фактически является буфером между вами и другим сервером, не получает ответ от другого сервера.

Отправка методом GET

Создание URL для GET-запроса

Для примера мы будем использовать запросы к Telegram bot API.

1. Добавим токен бота в URL-запрос.

Все запросы в Telegram создаются по шаблону:

https://api.telegram.org/bot<token>/НАЗВАНИЕ_МЕТОДА

Каждому боту при создании присваивается уникальный токен вида 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11.

Авторизация запросов к Telegram проходит по токену бота. Это значит, что срабатывать запрос будет в боте, токен которого вы указали. К примеру, отправляя запрос с текстом, вы можете указать токен другого бота, и тогда сообщение будет приходить в него.

Пока что URL будет таким:

 https://api.telegram.org/bot123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11/НАЗВАНИЕ_МЕТОДА

Где вместо 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11 — токен вашего бота.

2. Добавим метод API.

Метод API — действие, которое должна совершить система в заданном боте.

Один из самых простых методов — sendMessage. Он отправляет текст.

После вставки метода API наш шаблон выглядит так:

https://api.telegram.org/bot123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11/sendMessage

3. Добавим параметры запроса.

Параметры запроса — обязательные и дополнительные данные, которые конкретизируют, какое действие произойдёт. Например, параметры получателя или текст, который ему придет.

Обязательными параметрами являются chat_id и text:

• chat_id — уникальный идентификатор пользователя в Telegram. Его мы получаем из переменной {{this_user.platform_id}}. Чтобы отправить сообщение определённому пользователю, нужно вставить значение его переменной. В нашем примере мы выводим значение из переменных пользователя.
• text — текст сообщения, которое мы отправляем.

Для передачи пробелов в URL запроса нужно заменять их знаком +. Если отправить текст без замены, он оборвётся на первом пробеле.

Для запроса методом GET метод API и параметры передаются в URL запроса. Параметры от метода API отделяются знаком вопроса. Значение параметра отправляется после знака равенства. Между собой параметры отделяются знаком &.

4. Формируем шаблон GET-запроса.

https://api.telegram.org/bot123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11/sendMessage?параметр1=значение1&параметр2=значение2

Вместо параметра1 добавим chat_id, значение1 выведем из переменных {{this_user.platform_id}}.

При необходимости, в значении1 можно указать конкретное значение.

Вместо параметра2 добавим text, в значение2 напишем текст, который должен прийти в бота.

URL GET-запроса готов:

https://api.telegram.org/bot123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11/sendMessage?chat_id={{this_user.platform_id}}&text=Привет+из+бота!

Настройка компонента

1. Добавьте компонент Запрос на экран.

2. Выберите Метод запроса — GET.

3. Укажите URL запроса.

4. Укажите Экран, который исполнится при удачном выполнении запроса.

5. Укажите Экран, который выполнится при ошибке запроса.

6. Если требует API, добавьте дополнительные заголовки запроса в выпадающем меню компонента. Не удаляйте заголовки по умолчанию.

7. Задайте Имя переменной для тела ответа, если нужно записать ответ от сервера не в last_request, куда ответ приходит по умолчанию.

8. Задайте Имя переменной для кода ответа, если нужно записать ответ от сервера не в last_request_status_code, куда ответ приходит по умолчанию.

9. Задайте Имя переменной для заголовков ответа, если предполагается, что в заголовках придут важные данные. Например: токены авторизации, куки, подпись HMAC или еще что-то, что может потребоваться дальше для использования в боте.

10. Разверните настройки компонента для продолжения.

11. Отметьте галочками, какие статусы ответов будут считаться успешными, а какие — нет.

12. Для использования данных для авторизации по http basic authentication отметьте галочкой Использовать HTTP-авторизацию.

13. Отметьте галочкой Кодировать тело запроса, если нужно передать параметры по стандарту Юникод.

14. Отметьте галочкой Пропустить проверку HTTPS-сертификата, если у вас возникли проблемы с валидностью сертификата. Бот продолжит работу, но мы рекомендуем исправлять проблемы с сертификатом как можно быстрее.

Отправка методом POST

Создание URL для POST-запроса

Так как в POST запросе, параметры запроса и их значения составляют тело запроса, то в строке URL остаются только:

https://api.telegram.org/bot<token>/НАЗВАНИЕ_МЕТОДА

Где <token> — токен бота, где будет срабатывать запрос.</token>

Пример токена: 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11.

Название метода оставим, как в прошлом примере — sendMessage.

Получаем URL такого вида:

https://api.telegram.org/bot123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11/sendMessage

Параметры в URL, как в GET запросе, добавлять не нужно.

Для метода POST, в URL передаётся только метод API, параметры отправляются в теле запроса в формате JSON.

JSON — один из форматов данных. Он состоит из пар данных: ключ-значение. Ключ — название параметра, значение — значение параметра (может быть определенным или переменной).

Чтобы сделать тело с нашими параметрами, указываем их в формате JSON:

{
"chat_id": "{{this_user.platform_id}}",
"text": "Привет из бота!"
}

Важно следить за синтаксисом. Если вы забудете поставить хотя бы один символ, запрос не сработает. Это самая распространённая ошибка при отправке запросов.

Переносить строки можно с помощью n, но такие символы ломают JSON. Чтобы JSON не ломался, нужно экранировать таким образом: /n. Но так сделать не получится, если мы отправляем в переменной var текст от пользователя. В таком случае, нужно использовать хелпер escapeJsonEntities таким образом: {{escapeJsonEntities var}}.

Настройка компонента

1. Добавьте компонент Запрос на экран.

2. Выберите Метод запроса — POST.

3. Укажите URL запроса.

4. Укажите Экран, который исполнится при удачном выполнении запроса.

5. Укажите Экран, который выполнится при ошибке запроса.

6. Тело запроса для метода POST указывается, если того требует API. Поддерживается только в формате JSON.

7. Если требует API, добавьте дополнительные заголовки запроса в выпадающем меню компонента. Не удаляйте заголовки по умолчанию.

8. Задайте Имя переменной для тела ответа, если нужно записать ответ от сервера не в last_request, куда ответ приходит по умолчанию.

9. Задайте Имя переменной для кода ответа, если нужно записать ответ от сервера не в last_request_status_code, куда ответ приходит по умолчанию.

10. Задайте Имя переменной для заголовков ответа, если предполагается, что в заголовках придут важные данные. Например: токены авторизации, куки, подпись HMAC или еще что-то, что может потребоваться дальше для использования в боте.

11. Разверните настройки компонента для продолжения.

12. Отметьте галочками, какие статусы ответов будут считаться успешными, а какие — нет.

13. Для использования данных для авторизации по http basic authentication отметьте галочкой Использовать HTTP-авторизацию.

14. Отметьте галочкой Кодировать тело запроса, если нужно передать параметры по стандарту Юникод.

15. Отметьте галочкой Пропустить проверку HTTPS-сертификата, если у вас возникли проблемы с валидностью сертификата. Бот продолжит работу, но мы рекомендуем исправлять проблемы с сертификатом как можно быстрее.

Удаление последнего сообщения от бота с помощью POST-запроса

По правилам Телеграма нельзя удалять сообщения, после отправки которых прошло более 48 часов

Удаление последнего сообщения с помощью Нативного запроса →

Для тестирования метода POST можно попробовать удалить предыдущее сообщение методом deleteMessage.

Обязательные параметры:

• chat_id — уникальный идентификатор пользователя в боте. Его мы получаем как основную переменную {{this_user.platform_id}}.
• message_id — уникальный идентификатор сообщения, находится в переменной {{lastMessageId}}.

Создадим POST-запрос deleteMessage в конструкторе:

1. Добавьте компонент Запрос на экран.

2. Выберите Метод запроса — POST.

3. Укажите URL запроса.

Путь запроса (URL) будет иметь такой вид:

https://api.telegram.org/bot123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11/deleteMessage

Где где 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11 — токен вашего бота.

4. Укажите Экран, который исполнится при удачном выполнении запроса.

5. Укажите Экран, который выполнится при ошибке запроса.

6. Добавьте Тело запроса. Поддерживается тело только в формате JSON.

{
"chat_id": "{{this_user.platform_id}}",
"message_id": "{{lastMessageId}}"
}

7. Если требует API, добавьте дополнительные заголовки запроса в выпадающем меню компонента. Не удаляйте заголовки по умолчанию.

8. Задайте Имя переменной для тела ответа, если нужно записать ответ от сервера не в last_request, куда ответ приходит по умолчанию.

9. Задайте Имя переменной для кода ответа, если нужно записать ответ от сервера не в last_request_status_code, куда ответ приходит по умолчанию.

10. Задайте Имя переменной для заголовков ответа, если предполагается, что в заголовках придут важные данные. Например: токены авторизации, куки, подпись HMAC или еще что-то, что может потребоваться дальше для использования в боте.

11. Разверните настройки компонента для продолжения.

12. Отметьте галочками, какие статусы ответов будут считаться успешными, а какие — нет.

13. Для использования данных для авторизации по http basic authentication отметьте галочкой Использовать HTTP-авторизацию.

14. Отметьте галочкой Кодировать тело запроса, если нужно передать параметры по стандарту Юникод.

15. Отметьте галочкой Пропустить проверку HTTPS-сертификата, если у вас возникли проблемы с валидностью сертификата. Бот продолжит работу, но мы рекомендуем исправлять проблемы с сертификатом как можно быстрее.

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

Все шаги по созданию запроса на удаление последнего сообщения от чат-бота вы можете посмотреть в видеоуроке:

Подобным образом можно удалить последнее сообщение от пользователя.

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

Тело запроса будет таким:

{
"chat_id": "{{lastUpdate.update.chat.id}}",
"message_id": "{{lastUpdate.update.message_id}}"
}

Запрос должен срабатывать сразу после сообщения от пользователя, для этого необходимо перед запросом добавить компонент ожидающий ввода от пользователя.

Это может быть Развилка, Ввод от пользователя или на экран с запросом должна вести Перемотка с активным чекбоксом «‎Остановить бота после перемотки до следующего сообщения от пользователя».

Все шаги по созданию запроса на удаление последнего сообщения от пользователя вы можете посмотреть в видеоуроке:

Удаление любого сообщения с помощью POST-запроса

Методом deleteMessage также можно удалить любое сообщение от бота.

Для этого перезапишите {{lastMessageId}} удаляемого компонента в другую переменную с помощью компонента Запись переменной.

В поле Имя задайте новое имя переменной, в поле Значение впишите {{lastMessageId}}.

В нашем примере новое имя для переменной с сообщением — dlt.

В будущем добавим её в тело запроса на удаление в двойных фигурных скобках: {{dlt}}.

Для наглядного примера удаления любого сообщение от бота, а не только последнего, как в прошлом примере, экран с запросом добавим после всех сообщений.

После записи ID экрана в переменную, оформим запрос на удаление этого экрана.

Обязательные параметры:

• chat_id — уникальный идентификатор пользователя в боте. Его мы получаем как основную переменную {{this_user.platform_id}}.
• message_id — уникальный идентификатор сообщения, находится в переменной {{lastMessageId}}.

Создадим POST-запрос deleteMessage в конструкторе:

1. Добавьте компонент Запрос на экран.

2. Выберите Метод запроса — POST.

3. Укажите URL запроса.

Путь запроса (URL) будет иметь такой вид:

https://api.telegram.org/bot12345/deleteMessage

Где где 12345 — токен вашего бота.

4. Укажите Экран, который исполнится при удачном выполнении запроса.

5. Укажите Экран, который выполнится при ошибке запроса.

6. Добавьте Тело запроса. Поддерживается тело только в формате JSON.

Не забудем добавить нашу перезаписанную переменную в message_id.

    {
    "chat_id": "{{this_user.platform_id}}",
    "message_id": "{{dlt}}"
    }

7. Если требует API, добавьте дополнительные заголовки запроса в выпадающем меню компонента. Не удаляйте заголовки по умолчанию.

8. Задайте Имя переменной для тела ответа, если нужно записать ответ от сервера не в last_request, куда ответ приходит по умолчанию.

9. Задайте Имя переменной для кода ответа, если нужно записать ответ от сервера не в last_request_status_code, куда ответ приходит по умолчанию.

10. Задайте Имя переменной для заголовков ответа, если предполагается, что в заголовках придут важные данные. Например: токены авторизации, куки, подпись HMAC или еще что-то, что может потребоваться дальше для использования в боте.

11. Разверните настройки компонента для продолжения.

12. Отметьте галочками, какие статусы ответов будут считаться успешными, а какие — нет.

13. Для использования данных для авторизации по http basic authentication отметьте галочкой Использовать HTTP-авторизацию.

14. Отметьте галочкой Кодировать тело запроса, если нужно передать параметры по стандарту Юникод.

15. Отметьте галочкой Пропустить проверку HTTPS-сертификата, если у вас возникли проблемы с валидностью сертификата. Бот продолжит работу, но мы рекомендуем исправлять проблемы с сертификатом как можно быстрее.

Если все сделано правильно, то удаляться будет то сообщение, message_id которого мы перезаписали и затем добавили в Тело запроса.

Все шаги по созданию запроса на удаление любого сообщения от бота вы можете посмотреть в видеоуроке:

Отправка стикера с помощью POST-запроса

Отправим в чат стикер методом sendSticker.

Стикер можно отправлять как обычным Запросом к API, так и Нативным запросом.

Обязательные параметры:

• chat_id — уникальный идентификатор пользователя в боте. Его мы получаем как основную переменную {{this_user.platform_id}}.
• sticker — уникальный идентификатор стикера. ID стикера можно узнать, прислав стикер боту Sticker ID.

Создадим POST-запрос sendSticker в конструкторе:

1. Добавьте компонент Запрос на экран.

2. Выберите Метод запроса — POST.

3. Укажите URL запроса.

Путь запроса (URL) будет иметь такой вид:

https://api.telegram.org/bot123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11/sendSticker

Где 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11 — токен вашего бота.

4. Укажите Экран, который исполнится при удачном выполнении запроса.

5. Укажите Экран, который выполнится при ошибке запроса.

6. Добавьте Тело запроса. Поддерживается тело только в формате JSON.

{
"chat_id": "{{this_user.platform_id}}",
"sticker": "12345"
}

Где 12345 — ID отправляемого стикера.

7. Если требует API, добавьте дополнительные заголовки запроса в выпадающем меню компонента. Не удаляйте заголовки по умолчанию.

8. Задайте Имя переменной для тела ответа, если нужно записать ответ от сервера не в last_request, куда ответ приходит по умолчанию.

9. Задайте Имя переменной для кода ответа, если нужно записать ответ от сервера не в last_request_status_code, куда ответ приходит по умолчанию.

10. Задайте Имя переменной для заголовков ответа, если предполагается, что в заголовках придут важные данные. Например: токены авторизации, куки, подпись HMAC или еще что-то, что может потребоваться дальше для использования в боте.

11. Разверните настройки компонента для продолжения.

12. Отметьте галочками, какие статусы ответов будут считаться успешными, а какие — нет.

13. Для использования данных для авторизации по http basic authentication отметьте галочкой Использовать HTTP-авторизацию.

14. Отметьте галочкой Кодировать тело запроса, если нужно передать параметры по стандарту Юникод.

15. Отметьте галочкой Пропустить проверку HTTPS-сертификата, если у вас возникли проблемы с валидностью сертификата. Бот продолжит работу, но мы рекомендуем исправлять проблемы с сертификатом как можно быстрее.

Если все сделано верно, то при исполнении Запроса, в бот придет стикер.

Все шаги по созданию запроса для отправки стикера от бота вы можете посмотреть в видеоуроке:

Отправка запроса в GPT с помощью POST-запроса

Обратимся к GPT с помощью POST запроса. Ответ от нейросети выведем в боте.

Обязательные параметры:

• model — языковая модель, на котором нам ответит GPT, рекомендуем использовать text-davinci-003
• prompt — текст, который отправиться в GPT. Текст можно заранее записать в переменную и вывести в теле запроса
• max_tokens — максимальное количество символов в ответе от gpt. Значение может быть от 16 до 4000

Создадим POST-запрос к GPT в конструкторе:

1. Добавьте компонент Запрос на экран.

2. Выберите Метод запроса — POST.

3. Укажите URL запроса.

Путь запроса (URL) будет иметь такой вид:

https://api.openai.com/v1/completions

4. Укажите Экран, который исполнится при удачном выполнении запроса.

5. Укажите Экран, который выполнится при ошибке запроса.

6. Добавьте Тело запроса. Поддерживается тело только в формате JSON:

    {
      "model": "text-davinci-003",
      "prompt": "{{prompt}}",
      "max_tokens": 400
    }

7. Добавьте дополнительный заголовок запроса:

Ключ: Authorization
Значение: Bearer 12345xQWERTY, где 12345xQWERTY — ваш токен, который вы получили в OPEN AI.

Если доступ из вашей страны заблокирован, воспользуйтесь VPN.

Получить токен можно так:

Не удаляйте заголовки по умолчанию.

8. Задайте Имя переменной для тела ответа, если нужно записать ответ от сервера не в last_request, куда ответ приходит по умолчанию.

9. Чтобы ответ от GPT, приходил сразу в бот, добавьте сообщение, где будет выводиться переменная с ответом. Если вы не меняли переменную для ответа по умолчанию, добавьте такой шаблон:

{{last_request.choices.[0].text}}

10. После ответа, можно добавить Перемотку на тот же самый экран, чтобы бы не перезапускать сценарий для нового обращения к GPT.

Обработка ответа — объект

Для примера мы будем использовать ресурс https://www.cbr-xml-daily.ru.

В нём мы выбираем запрос в формате JSON:

https://www.cbr-xml-daily.ru/daily_json.js

Открываем его как обычную ссылку в браузере и получаем ответ в JSON-формате.

Чтобы ответ был удобным для чтения, поставьте расширение на браузер. Для Google Chrome это JSON Formatter.

Например, мы хотим получить стоимость 1 белорусского рубля. Находим часть, где выводится значение BYN и составляем переменную.

Ответ на запрос находится в объекте {{last_request}}.

Чтобы вывести переменную внутри текста, вводим её внутри фигурных скобок. Для этого делаем запрос и выводим полученный ответ в тексте.

В начало ↑

Если для пользователей в первую очередь важно качество контента, то для поисковых роботов — ответ сервера. При анализе страницы поисковые системы сначала смотрят на код ответа и только потом анализируют содержимое документа. В случае отправки неверно сформированных кодов ваш сайт рискует утратить позиции в выдаче. Чтобы избежать этого, проверяйте ответы сервера и при выявлении сбоев оперативно устраняйте их.

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

Что такое код ответа

Код ответа сервера — это ответ сервера на действия пользователя. Он представляет собой целое трёхзначное число, в котором первая цифра определяет класс состояния. Обычно за кодом ответа находится фраза на английском языке — она объясняет человека причину полученного ответа и подсказывает, что делать дальше.

Отправка методом POST

Создание URL для POST-запроса

Так как в POST запросе, параметры запроса и их значения составляют тело запроса, то в строке URL остаются только:

https://api.telegram.org/bot<token>/НАЗВАНИЕ_МЕТОДА

Где <token> — токен бота, где будет срабатывать запрос.</token>

Пример токена: 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11.

Название метода оставим, как в прошлом примере — sendMessage.

Получаем URL такого вида:

https://api.telegram.org/bot123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11/sendMessage

Параметры в URL, как в GET запросе, добавлять не нужно.

Для метода POST, в URL передаётся только метод API, параметры отправляются в теле запроса в формате JSON.

JSON — один из форматов данных. Он состоит из пар данных: ключ-значение. Ключ — название параметра, значение — значение параметра (может быть определенным или переменной).

Чтобы сделать тело с нашими параметрами, указываем их в формате JSON:

{
"chat_id": "{{this_user.platform_id}}",
"text": "Привет из бота!"
}

Важно следить за синтаксисом. Если вы забудете поставить хотя бы один символ, запрос не сработает. Это самая распространённая ошибка при отправке запросов.

Переносить строки можно с помощью n, но такие символы ломают JSON. Чтобы JSON не ломался, нужно экранировать таким образом: /n. Но так сделать не получится, если мы отправляем в переменной var текст от пользователя. В таком случае, нужно использовать хелпер escapeJsonEntities таким образом: {{escapeJsonEntities var}}.

Настройка компонента

1. Добавьте компонент Запрос на экран.

2. Выберите Метод запроса — POST.

3. Укажите URL запроса.

4. Укажите Экран, который исполнится при удачном выполнении запроса.

5. Укажите Экран, который выполнится при ошибке запроса.

6. Тело запроса для метода POST указывается, если того требует API. Поддерживается только в формате JSON.

7. Если требует API, добавьте дополнительные заголовки запроса в выпадающем меню компонента. Не удаляйте заголовки по умолчанию.

8. Задайте Имя переменной для тела ответа, если нужно записать ответ от сервера не в last_request, куда ответ приходит по умолчанию.

9. Задайте Имя переменной для кода ответа, если нужно записать ответ от сервера не в last_request_status_code, куда ответ приходит по умолчанию.

10. Задайте Имя переменной для заголовков ответа, если предполагается, что в заголовках придут важные данные. Например: токены авторизации, куки, подпись HMAC или еще что-то, что может потребоваться дальше для использования в боте.

11. Разверните настройки компонента для продолжения.

12. Отметьте галочками, какие статусы ответов будут считаться успешными, а какие — нет.

13. Для использования данных для авторизации по http basic authentication отметьте галочкой Использовать HTTP-авторизацию.

14. Отметьте галочкой Кодировать тело запроса, если нужно передать параметры по стандарту Юникод.

15. Отметьте галочкой Пропустить проверку HTTPS-сертификата, если у вас возникли проблемы с валидностью сертификата. Бот продолжит работу, но мы рекомендуем исправлять проблемы с сертификатом как можно быстрее.

Удаление последнего сообщения от бота с помощью POST-запроса

По правилам Телеграма нельзя удалять сообщения, после отправки которых прошло более 48 часов

Удаление последнего сообщения с помощью Нативного запроса →

Для тестирования метода POST можно попробовать удалить предыдущее сообщение методом deleteMessage.

Обязательные параметры:

• chat_id — уникальный идентификатор пользователя в боте. Его мы получаем как основную переменную {{this_user.platform_id}}.
• message_id — уникальный идентификатор сообщения, находится в переменной {{lastMessageId}}.

Создадим POST-запрос deleteMessage в конструкторе:

1. Добавьте компонент Запрос на экран.

2. Выберите Метод запроса — POST.

3. Укажите URL запроса.

Путь запроса (URL) будет иметь такой вид:

https://api.telegram.org/bot123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11/deleteMessage

Где где 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11 — токен вашего бота.

4. Укажите Экран, который исполнится при удачном выполнении запроса.

5. Укажите Экран, который выполнится при ошибке запроса.

6. Добавьте Тело запроса. Поддерживается тело только в формате JSON.

{
"chat_id": "{{this_user.platform_id}}",
"message_id": "{{lastMessageId}}"
}

7. Если требует API, добавьте дополнительные заголовки запроса в выпадающем меню компонента. Не удаляйте заголовки по умолчанию.

8. Задайте Имя переменной для тела ответа, если нужно записать ответ от сервера не в last_request, куда ответ приходит по умолчанию.

9. Задайте Имя переменной для кода ответа, если нужно записать ответ от сервера не в last_request_status_code, куда ответ приходит по умолчанию.

10. Задайте Имя переменной для заголовков ответа, если предполагается, что в заголовках придут важные данные. Например: токены авторизации, куки, подпись HMAC или еще что-то, что может потребоваться дальше для использования в боте.

11. Разверните настройки компонента для продолжения.

12. Отметьте галочками, какие статусы ответов будут считаться успешными, а какие — нет.

13. Для использования данных для авторизации по http basic authentication отметьте галочкой Использовать HTTP-авторизацию.

14. Отметьте галочкой Кодировать тело запроса, если нужно передать параметры по стандарту Юникод.

15. Отметьте галочкой Пропустить проверку HTTPS-сертификата, если у вас возникли проблемы с валидностью сертификата. Бот продолжит работу, но мы рекомендуем исправлять проблемы с сертификатом как можно быстрее.

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

Все шаги по созданию запроса на удаление последнего сообщения от чат-бота вы можете посмотреть в видеоуроке:

Подобным образом можно удалить последнее сообщение от пользователя.

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

Тело запроса будет таким:

{
"chat_id": "{{lastUpdate.update.chat.id}}",
"message_id": "{{lastUpdate.update.message_id}}"
}

Запрос должен срабатывать сразу после сообщения от пользователя, для этого необходимо перед запросом добавить компонент ожидающий ввода от пользователя.

Это может быть Развилка, Ввод от пользователя или на экран с запросом должна вести Перемотка с активным чекбоксом «‎Остановить бота после перемотки до следующего сообщения от пользователя».

Все шаги по созданию запроса на удаление последнего сообщения от пользователя вы можете посмотреть в видеоуроке:

Удаление любого сообщения с помощью POST-запроса

Методом deleteMessage также можно удалить любое сообщение от бота.

Для этого перезапишите {{lastMessageId}} удаляемого компонента в другую переменную с помощью компонента Запись переменной.

В поле Имя задайте новое имя переменной, в поле Значение впишите {{lastMessageId}}.

В нашем примере новое имя для переменной с сообщением — dlt.

В будущем добавим её в тело запроса на удаление в двойных фигурных скобках: {{dlt}}.

Для наглядного примера удаления любого сообщение от бота, а не только последнего, как в прошлом примере, экран с запросом добавим после всех сообщений.

После записи ID экрана в переменную, оформим запрос на удаление этого экрана.

Обязательные параметры:

• chat_id — уникальный идентификатор пользователя в боте. Его мы получаем как основную переменную {{this_user.platform_id}}.
• message_id — уникальный идентификатор сообщения, находится в переменной {{lastMessageId}}.

Создадим POST-запрос deleteMessage в конструкторе:

1. Добавьте компонент Запрос на экран.

2. Выберите Метод запроса — POST.

3. Укажите URL запроса.

Путь запроса (URL) будет иметь такой вид:

https://api.telegram.org/bot12345/deleteMessage

Где где 12345 — токен вашего бота.

4. Укажите Экран, который исполнится при удачном выполнении запроса.

5. Укажите Экран, который выполнится при ошибке запроса.

6. Добавьте Тело запроса. Поддерживается тело только в формате JSON.

Не забудем добавить нашу перезаписанную переменную в message_id.

    {
    "chat_id": "{{this_user.platform_id}}",
    "message_id": "{{dlt}}"
    }

7. Если требует API, добавьте дополнительные заголовки запроса в выпадающем меню компонента. Не удаляйте заголовки по умолчанию.

8. Задайте Имя переменной для тела ответа, если нужно записать ответ от сервера не в last_request, куда ответ приходит по умолчанию.

9. Задайте Имя переменной для кода ответа, если нужно записать ответ от сервера не в last_request_status_code, куда ответ приходит по умолчанию.

10. Задайте Имя переменной для заголовков ответа, если предполагается, что в заголовках придут важные данные. Например: токены авторизации, куки, подпись HMAC или еще что-то, что может потребоваться дальше для использования в боте.

11. Разверните настройки компонента для продолжения.

12. Отметьте галочками, какие статусы ответов будут считаться успешными, а какие — нет.

13. Для использования данных для авторизации по http basic authentication отметьте галочкой Использовать HTTP-авторизацию.

14. Отметьте галочкой Кодировать тело запроса, если нужно передать параметры по стандарту Юникод.

15. Отметьте галочкой Пропустить проверку HTTPS-сертификата, если у вас возникли проблемы с валидностью сертификата. Бот продолжит работу, но мы рекомендуем исправлять проблемы с сертификатом как можно быстрее.

Если все сделано правильно, то удаляться будет то сообщение, message_id которого мы перезаписали и затем добавили в Тело запроса.

Все шаги по созданию запроса на удаление любого сообщения от бота вы можете посмотреть в видеоуроке:

Отправка стикера с помощью POST-запроса

Отправим в чат стикер методом sendSticker.

Стикер можно отправлять как обычным Запросом к API, так и Нативным запросом.

Обязательные параметры:

• chat_id — уникальный идентификатор пользователя в боте. Его мы получаем как основную переменную {{this_user.platform_id}}.
• sticker — уникальный идентификатор стикера. ID стикера можно узнать, прислав стикер боту Sticker ID.

Создадим POST-запрос sendSticker в конструкторе:

1. Добавьте компонент Запрос на экран.

2. Выберите Метод запроса — POST.

3. Укажите URL запроса.

Путь запроса (URL) будет иметь такой вид:

https://api.telegram.org/bot123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11/sendSticker

Где 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11 — токен вашего бота.

4. Укажите Экран, который исполнится при удачном выполнении запроса.

5. Укажите Экран, который выполнится при ошибке запроса.

6. Добавьте Тело запроса. Поддерживается тело только в формате JSON.

{
"chat_id": "{{this_user.platform_id}}",
"sticker": "12345"
}

Где 12345 — ID отправляемого стикера.

7. Если требует API, добавьте дополнительные заголовки запроса в выпадающем меню компонента. Не удаляйте заголовки по умолчанию.

8. Задайте Имя переменной для тела ответа, если нужно записать ответ от сервера не в last_request, куда ответ приходит по умолчанию.

9. Задайте Имя переменной для кода ответа, если нужно записать ответ от сервера не в last_request_status_code, куда ответ приходит по умолчанию.

10. Задайте Имя переменной для заголовков ответа, если предполагается, что в заголовках придут важные данные. Например: токены авторизации, куки, подпись HMAC или еще что-то, что может потребоваться дальше для использования в боте.

11. Разверните настройки компонента для продолжения.

12. Отметьте галочками, какие статусы ответов будут считаться успешными, а какие — нет.

13. Для использования данных для авторизации по http basic authentication отметьте галочкой Использовать HTTP-авторизацию.

14. Отметьте галочкой Кодировать тело запроса, если нужно передать параметры по стандарту Юникод.

15. Отметьте галочкой Пропустить проверку HTTPS-сертификата, если у вас возникли проблемы с валидностью сертификата. Бот продолжит работу, но мы рекомендуем исправлять проблемы с сертификатом как можно быстрее.

Если все сделано верно, то при исполнении Запроса, в бот придет стикер.

Все шаги по созданию запроса для отправки стикера от бота вы можете посмотреть в видеоуроке:

Отправка запроса в GPT с помощью POST-запроса

Обратимся к GPT с помощью POST запроса. Ответ от нейросети выведем в боте.

Обязательные параметры:

• model — языковая модель, на котором нам ответит GPT, рекомендуем использовать text-davinci-003
• prompt — текст, который отправиться в GPT. Текст можно заранее записать в переменную и вывести в теле запроса
• max_tokens — максимальное количество символов в ответе от gpt. Значение может быть от 16 до 4000

Создадим POST-запрос к GPT в конструкторе:

1. Добавьте компонент Запрос на экран.

2. Выберите Метод запроса — POST.

3. Укажите URL запроса.

Путь запроса (URL) будет иметь такой вид:

https://api.openai.com/v1/completions

4. Укажите Экран, который исполнится при удачном выполнении запроса.

5. Укажите Экран, который выполнится при ошибке запроса.

6. Добавьте Тело запроса. Поддерживается тело только в формате JSON:

    {
      "model": "text-davinci-003",
      "prompt": "{{prompt}}",
      "max_tokens": 400
    }

7. Добавьте дополнительный заголовок запроса:

Ключ: Authorization
Значение: Bearer 12345xQWERTY, где 12345xQWERTY — ваш токен, который вы получили в OPEN AI.

Если доступ из вашей страны заблокирован, воспользуйтесь VPN.

Получить токен можно так:

Не удаляйте заголовки по умолчанию.

8. Задайте Имя переменной для тела ответа, если нужно записать ответ от сервера не в last_request, куда ответ приходит по умолчанию.

9. Чтобы ответ от GPT, приходил сразу в бот, добавьте сообщение, где будет выводиться переменная с ответом. Если вы не меняли переменную для ответа по умолчанию, добавьте такой шаблон:

{{last_request.choices.[0].text}}

10. После ответа, можно добавить Перемотку на тот же самый экран, чтобы бы не перезапускать сценарий для нового обращения к GPT.

Обработка ответа — объект

Для примера мы будем использовать ресурс https://www.cbr-xml-daily.ru.

В нём мы выбираем запрос в формате JSON:

https://www.cbr-xml-daily.ru/daily_json.js

Открываем его как обычную ссылку в браузере и получаем ответ в JSON-формате.

Чтобы ответ был удобным для чтения, поставьте расширение на браузер. Для Google Chrome это JSON Formatter.

Например, мы хотим получить стоимость 1 белорусского рубля. Находим часть, где выводится значение BYN и составляем переменную.

Ответ на запрос находится в объекте {{last_request}}.

Чтобы вывести переменную внутри текста, вводим её внутри фигурных скобок. Для этого делаем запрос и выводим полученный ответ в тексте.

В начало ↑

Если для пользователей в первую очередь важно качество контента, то для поисковых роботов — ответ сервера. При анализе страницы поисковые системы сначала смотрят на код ответа и только потом анализируют содержимое документа. В случае отправки неверно сформированных кодов ваш сайт рискует утратить позиции в выдаче. Чтобы избежать этого, проверяйте ответы сервера и при выявлении сбоев оперативно устраняйте их.

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

Что такое код ответа

Код ответа сервера — это ответ сервера на действия пользователя. Он представляет собой целое трёхзначное число, в котором первая цифра определяет класс состояния. Обычно за кодом ответа находится фраза на английском языке — она объясняет человека причину полученного ответа и подсказывает, что делать дальше.

Пример кода ответа сервера

Набор кодов состояния — стандарт. Все коды описаны в серии пронумерованных информационных документов интернета RFC. Введение новых кодов возможно, но только после согласования c IETF — Инженерным советом Интернета.

Анализ кода состояния HTTP помогает определить доступность веб-страницы. Технически это выглядит так: когда вы переходите по ссылке на сайте или просто вводите её в поисковой строке браузера, отправляется стандартный запрос. Сервер самостоятельно обрабатывает его, а затем формирует и отдаёт трёхзначный цифровой код

Код делает так, чтобы реакцию сайта на запрос могли понять не только поисковые машины, но и обычные пользователи.

В кодах сервера нет ничего сложного даже для начинающих вебмастеров. Главное — определиться с терминами:

• Клиент — компьютер или любое другое устройство, подключённое к интернету.
• Сервер — конкретный компьютер, где хранятся все данные сайта, в том числе страницы и системные файлы.

Когда важно настроить коды ответов сервера

Когда запрос успешно обрабатывается, пользователь открывает нужную страницу в браузере, а поисковая система приступает к сканированию её содержимого. Корректный статус сервера способствует быстрой индексации, что очень важно при SEO-продвижении.

Настраивать HTTP-коды необходимо, если на сайте произошли какие-то изменения. Например, удаление старых страниц, переход на новую CMS или смена URL-адреса. Корректировка кодов нужна, чтобы управлять индексацией поисковыми системами и перенаправлять пользователей с неработающей страницы на рабочую.

Классификация кодов

Ответы сервера — трёхзначные коды с небольшим текстовым пояснением. Чтобы ориентироваться в них было проще, их делят на классы состояния. Основной классификационный признак — первая цифра трёхзначного кода.

Значения первых цифр кода ответа сервера:

• 1xx — коды информации. Они говорят об успешном получении запроса и начале передачи данных.
• 2xx — коды успешного выполнения запроса. Сигнализируют о положительном ответе сервера в браузере.
• 3xx — коды перенаправления. Отвечают за переадресацию, используются для навигации между URL.
• 4xx — коды HTTP-ошибок на стороне пользователя.
• 5xx — коды HTTP-ошибок в работе сервера. Точная причина сбоя указывается сразу после кода.

Ниже более подробно разберём классы состояния ответов сервера. Для самых часто встречающихся укажем причины и решения ошибок.

Коды информации

В класс 1xx включены коды, которые информируют о процессе передачи.

100 Continue — сервер удовлетворён начальными сведениями о запросе. Устройство-клиент может продолжать отправку данных.

101 Switching Protocols — сервер учитывает пользовательские требования и переключает протоколы.

102 Processing — запрос поступил на сервер, но для его обработки требуется время. Ответ необходим, чтобы клиент не разорвал соединение из-за превышения лимита ожидания.

103 Early Hints — сервер загружает элементы заголовков, если заголовки полного ответа не могут быть сформированы быстро.

Коды успешного выполнения запроса

Ответы класса 2xx показывают, что клиентский запрос был принят и успешно обработан.

200 OK — успешный запрос. Клиент запросил определённые данные, и они отобразились в заголовке или теле сообщения.

201 Created — завершённая транзакция. В результате выполнения запроса появился новый ресурс. Его адрес указывается в теле ответа или заголовке Location.

202 Accepted — запрос принят, но процесс его обработки не завершился. Клиент может не дожидаться передачи сообщения, так как это займёт много времени.

203 Non-Authoritative Information — информацию для передачи взяли не с исходного сервера, а какого-то другого. Данные могут быть устаревшими.

204 No Content — запрос обработан, но содержимое отсутствует. Сервер обработал запрос, но передал только заголовки без тела сообщения.

205 Reset Content — требуется сбросить содержимое. Клиенту нужно обновить введённые пользователем данные, но саму страницу перезагружать не нужно.

206 Partial Content — ошибка частичного содержимого. Клиент загружал данные в несколько потоков, но сервер выполнил частичный GET-запрос. Чтобы устранить ошибку, почистите кэш и проверьте, как выполняются исходящие запросы.

207 Multi-Status — набор выполненных операций. Сервер передал результаты выполнения нескольких операций — они находятся в XML в строке MultiStatus.

Коды перенаправления

Коды класса 3xx сообщают клиенту, что для завершения операции нужно сделать другой запрос.

300 Multiple Choices — не удалось определить точный URL. Существует несколько вариантов предоставления ресурса по разным характеристикам. Сервер передаёт с сообщением список альтернатив, клиент самостоятельно делает выбор.

301 Moved Permanently — документ перемещён на новый URL. Так отвечают все веб-страницы, которые удалены или являются дублями. Со временем они автоматически присоединяются к целевой странице. Если возникла ошибка: настройте 301-ое перенаправление с устаревшего адреса на актуальный.

302 Moved Temporarily — запрошенный документ временно доступен по другому URL. Корректный ответ сервера, который часто используется для страниц с распродажами и сезонными акциями. Клиент находит нужную страницу, несмотря на то что она перенесена.

303 See Other — документ нужно запросить по другому адресу. Такой код получают исключительно GET-запросом. Обычно его используют, если нужно перенаправить пользователя на близкорелевантную, но не идентичную страницу.

304 Not Modified — документ не изменился с указанного момента. Код — стандартный редирект. Помогает поисковым роботам находить страницы, которые не изменились с последнего визита пользователя.

305 Use Proxy — доступ к запрашиваемому ресурсу возможен только через прокси-сервер.

307 Temporary Redirect — документ временно доступен по другому URL. Код разрешает не менять метод запроса. Нужен, чтобы перенаправлять пользователей, но оставлять техническую возможность отправки POST-запросов.

308 Permanent Redirect — запрашиваемый документ окончательно перенесён на новый URL.

Коды HTTP-ошибок на стороне клиента

Класс кодов 4xx помогает найти ошибки со стороны клиента. В теле сообщения сервер отправляет текстовое пояснение для пользователя.

400 Bad Request — некорректный запрос. Сервер обнаружил в запросе клиента синтаксическую ошибку. Чтобы исправить её, проверьте корректность отправляемого запроса.

401 Unauthorized — отсутствует аутентификация. Для получения доступа к запрашиваемому ресурсу клиент должен зарегистрироваться или ввести пароль.

402 Payment Required — отсутствует доступ к документу. Такой код обычно используется платными пользовательскими сервисами. Доступ закрывается, если просрочена оплата.

403 Forbidden — доступ запрещён. Сервер обработал запрос, но отказывается выполнять его из-за ограничений к указанному ресурсу. Наиболее вероятная причина ограничения — попытка доступа к системным ресурсам веб-сервера или к закрытым файлам.

404 Not Found — отсутствует запрос по введённому URL. Обычно ошибка возникает из-за неправильно написанного адреса веб-страницы. Убедитесь, что вы ввели данные правильно.

405 Method Not Allowed — некорректный метод. Указанный клиентом метод запроса нельзя применить к текущему ресурсу. В теле сообщения сервер укажет доступные методы в заголовке Allow.

406 Not Acceptable — неподдерживаемый формат запроса. Сервер не может прислать методы, которые применимы к текущему запросу. Причина — неспособность поисковой системы поддерживать кодировку документа или его язык. Посмотрите в теле сообщения лист доступных ресурсов и выберите один из вариантов.

407 Proxy Authentication Required — отсутствует регистрация прокси. Механизм аналогичен идентификации на исходном сервере по коду 401.

408 Request Timeout — таймаут запроса. Время ожидания сервером истекло, но клиент может повторить аналогичный запрос. Ошибка возникает, если в какой-то момент источник данных перестал отвечать, например, из-за внутренних повреждений или потери связи. Чтобы исправить, проверьте наличие интернета, а затем обновите страницу.

409 Conflict — несовместимость двух запросов. Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Частая причина ошибки — операции с методом PUT. Например, если нужно скачать файл, возраст которого превышает возраст того, что уже размещён на сервере.

410 Gone — ресурс больше не существует по указанному URL, страница удалена или недоступна. Если навсегда удаляете страницу, сделайте так, чтобы она давала именно 410-ый ответ. Тогда поисковый робот научится обходить её. Если удаляете временно, эффективнее использовать 404-ый ответ.

411 Length Required — сервер отклонил отправляемый запрос, поскольку не нашёл значение Content-Length. Ответ может быть получен как при обычных POST-запросах, так и при PUT-запросах.

412 Precondition Failed — ни одно из условных полей заголовка не выполнено. Как исправить: проверьте корректность и соблюдение HTTP-заголовков.

413 Payload Too Large — сервер отказал в обработке запроса из-за слишком большого размера. Браузеры поддерживают запросы от 2 до 8 килобайт.

414 URI Too Long — сервер отказал в обработке запроса из-за слишком длинного URL. Ошибку можно спровоцировать, если вы пытались передать длинные параметры через метод GET, а не POST.

415 Unsupported Media Type — некорректный медиаформат. Сервер не смог работать с указанным типом данных при выбранном методе.

416 Range Not Satisfiable — некорректно указанный диапазон, с которым не может взаимодействовать сервис. Ошибка возникает, если допущена опечатка в синтаксисе или диапазон отсутствует в необходимом документе. Чтобы исправить, проверьте синтаксис значения Range и обновите страницу.

417 Expectation Failed — сервер некорректно идентифицирует значение поля Expect заголовка запроса. Вы не сможете самостоятельно устранить ошибку, но можете обратиться в поддержку, если используете прокси Squid. Ещё один вариант — разрешить BS_PingHost обращаться к сети без участия прокси.

422 Unprocessable Entity — сервер принял запрос и может работать с указанным видом данных, но имеется какая-то логическая ошибка, мешающая выполнить операцию. Код не укажет, какая именно ошибка допущена, но чаще всего найти её удаётся в семантике документа.

423 Locked — используемый ресурс заблокировали, поскольку HTTP-метод был выбран неправильно. Перезагрузите интернет-роутер и компьютер, повторите операцию.

424 Failed Dependency — ресурс заблокировали в целях безопасности. Такой ответ отдаётся при наличии признаков несанкционированного доступа к CMS-файлам.

426 Upgrade Required — для продолжения работу клиенту необходимо обновить протокол. Ошибка возникает, если сервер требует обновление до SSL-протокола, а у клиента нет его поддержки.

429 Too Many Requests — клиент пытался отправить слишком много запросов за короткий промежуток времени. Ошибка возникает, потому что такая активность напоминает DDoS-атаки. Чтобы исправить её, отключите все плагины CMS, а затем включите их по очереди. Так вы найдёте источник проблемы.

451 Unavailable For Legal Reasons — доступ к странице закрыт по решению суда. Наиболее частая причина — нарушение авторских прав. Вы можете попытаться создать дубли, но рано или поздно ресурс с идентичным содержимым заблокируют. Временное решение — сменить домен. Но лучше всего — не нарушать закон.

Коды HTTP-ошибок на стороне сервера

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

500 Internal Server Error — любой внутренний сбой сервера, из-за которого не удаётся выполнить запрос. Часто проблема заключается в некорректно указанных директивах в системных файлах или в опечатках внутри скриптов. Как исправить ошибку: проверьте конфликты плагинов и дополнений. Возможно, в настройках административной панели указана одна версия PHP, а на сайте применяется другая, из-за чего создаётся высокая нагрузка на хостинг.

501 Not Implemented — не поддерживаются возможности, необходимые для обработки запроса. Сервер не понимает выбранный метод запроса, поэтому происходит ошибка. Исправить её самостоятельно вы не сможете.

502 Bad Gateway — сбой шлюза. Вышестоящий сервер отправил некорректный ответ серверу, выступающему в роли шлюза или прокси-сервера.

503 Service Unavailable — запрос не обработан по техническим причинам. Ошибка возникает, если сервер на обслуживании или сильно перегружен. Убедитесь, что пропускная способность сервера не ограничена профилактическими работами и отключите VPN.

504 Gateway Timeout — прокси-сервер не дождался ответа от вышестоящего сервера. Попробуйте обновить страницу. А если не помогло — почистите DNS-кэш. Для этого нажмите клавиши Windows и R, введите команду cmd. В открывшемся окне выберите ipconfig/flushdns и нажмите Enter.

505 HTTP Version Not Supported — сервер не поддерживает выбранную версию HTTP-протокола.

507 Insufficient Storage — на жёстком диске отсутствует место для выполнения запроса.

510 Not Extended — на сервере нет расширения, которое пытается использовать клиент. В теле сообщения сервер укажет, какие расширения доступны.

Как узнать код ответа сервера

Вы можете проверить код ответа сервера через опции браузера или специальные приложения. Например, в Google Chrome значение кода отображено в графе Status в разделе Network. Чтобы получить данные:

• откройте в браузере нужную страницу;
• активируйте функциональную панель вебмастера, нажав кнопку F12.

Ещё один вариант узнать ответ веб-страницы — использовать готовые сервисы: bertal, 2ip, cy-pr, wwhois, 4seo.

Рассмотрим, как они работают на примере mainspy:

1. Перейдите на официальный сайт сервиса.

1. Укажите URL для проверки — один или несколько.

1. Нажмите кнопку «Проверить».

В течение нескольких секунд на экране отобразится отчёт, в котором напротив каждого URL будет стоять код ответа сервера.

Анализировать коды ответа сервера могут не только поисковые роботы, но и люди. Научившись проверять их и правильно интерпретировать значения, вы сможете быстро определить, где ошибка при выполнении HTTP запроса и как её устранить.

Чтобы правильно истолковать ответ такого севера, базовых знаний недостаточно. Записывайтесь на курсы по веб-разработке, чтобы восполнить пробелы в знаниях и научитесь переводить такие коды ответов на человеческий язык.

Во время запроса информации с удаленного веб-сервера может возникнуть ошибка. Тогда веб-сервер посылает в ответ код ошибки HTTP. Например 404 — Not Found (ресурс не найден).

Коды состояния HTTP состоят из трех цифр от 100 и до 510. Они делятся на следующие группы:

1. Информационные (100-105).
2. Успешные (200-226).
3. Перенаправление (300-307).
4. Ошибка клиента (400-499).
5. Ошибка сервера (500-510).

Чтобы получить сведения об ошибке, введите её код в поле поиска по странице. Для этого нажмите сочетание клавиш CTRL + F и укажите номер.

100

Continue
Cервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.

101

Switching Protocols
Сервер предлагает перейти на более подходящий для указанного ресурса протокол; список предлагаемых протоколов сервер обязательно указывает в поле заголовкаUpdate. Если клиента это заинтересует, то он посылает новый запрос с указанием другого протокола. Появился в HTTP/1.1.

102

Processing
Запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.

200

ОК
Успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.

201

Created
В результате успешного выполнения запроса был создан новый ресурс. Сервер должен указать его местоположение в заголовке Location. Серверу рекомендуется[источник не указан 336 дней] ещё указывать в заголовке характеристики созданного ресурса (например, в поле Content-Type). Если сервер не уверен, что ресурс действительно будет существовать к моменту получения данного сообщения клиентом, то лучше использовать ответ с кодом 202. Появился в HTTP/1.0.

202

Accepted
Запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.

203

Non-Authoritative Information
Аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.

204

No Content
Сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.

205

Reset Content
Сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.

206

Partial Content
Сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1. (подробнее…)

207

Multi-Status
Сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.

226

IM Used
Заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

300

Multiple Choices
По указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.

301

Moved Permanently
Запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.

302

Found, Moved Temporarily
Запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, приуправляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.

303

See Other
Документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с 307-ым для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.

304

Not Modified
Сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.

305

Use Proxy
Запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.

306

(зарезервировано)
использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).

307

Temporary Redirect
Запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).

400

Bad Request
Сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.

401

Unauthorized
Для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Клиент может повторить запрос, включив в заголовок сообщения поле Authorization с требуемыми для аутентификации данными.

402

Payment Required
Предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговыхкомпаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

403

Forbidden
Сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401 или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае клиенту следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.

404

Not Found
Самая распространенная ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URI. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.

405

Method Not Allowed
Указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.

406

Not Acceptable
Запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.

407

Proxy Authentication Required
Ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.

408

Request Timeout
Время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потеря связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.

409

Conflict
Запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT.Появился в HTTP/1.1.

410

Gone
Такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа, например, копии). Если у сервера есть подозрение, что документ в ближайшее время может быть восстановлен, то лучше клиенту передать код 404. Появился в HTTP/1.1.

411

Length Required
Для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.

412

Precondition Failed
Возвращается, если ни одно из условных полей заголовка[неизвестный термин] запроса не было выполнено. Появился в HTTP/1.1.

413

Request Entity Too Large
Возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1.

414

Request-URL Too Long
Сервер не может обработать запрос из-за слишком длинного указанного URL. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1.

415

Unsupported Media Type
По каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.

416

Requested Range Not Satisfiabl
В поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges[источник не указан 336 дней]. Введено в RFC 2616 (обновление HTTP/1.1).

417

Expectation Failed
По каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).

422

Unprocessable Entity
Сервер успешно принял запрос, может работать с указанным видом данных, в теле запроса XML-документ имеет верный синтаксис, но имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.

423

Locked
Целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.

424

Failed Dependency
Реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.

425

Unordered Collection —
Посылается, если клиент послал запрос, обозначив положение в неотсортированной коллекции или используя порядок следования элементов, отличный от серверного[уточнить]. Введено в черновике по WebDAV Advanced Collections Protocol[14].

426

Upgrade Required
Сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено вRFC 2817 для возможности перехода к TLS посредством HTTP.

449

Retry With
Возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент как минимум используется программой Microsoft Money.

456

Unrecoverable Error
Возвращается сервером, если обработка запроса вызывает некорректируемые сбои в таблицах баз данных[источник не указан 336 дней]. Введено корпорацией Microsoftдля WebDAV.

500

Internal Server Error
Любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.

501

Not Implemented
Сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.

502

Bad Gateway
Сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. Появился в HTTP/1.0.

503

Service Unavailable
Сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.

504

Gateway Timeout
Сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.

505

HTTP Version Not Supported
Сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.

506

Variant Also Negotiates
В результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.

507

Insufficient Storage
Не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.

509

Bandwidth Limit Exceeded
Используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.

510

Not Extended
На сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.

Эти коды определены www.w3.org/Protocols/rfc2616/rfc2616-sec10.html:

Информационный (Informational 1xx)

Ответы в диапазоне 100-199 — информационные. Они показывают, что запрос клиента принят и обрабатывается.

100=»Continue»
Начальная часть запроса принята, и клиент может продолжать передачу запроса.

101=»Switching Protocols»
Сервер выполняет требование клиента и переключает протоколы в соответствии с указанием, данным в поле заголовка Upgrade.

Запрос клиента успешен (Successful 2xx)

Ответы в диапазоне 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.

233=»Because not everyone lives in «your country»»

Запрос клиента переадресован (Redirection 3xx)

Код ответа в диапазоне 300-399 означает, что запрос не выполнен и клиенту нужно предпринять некоторые действия для удовлетворения запроса.

300=»Multiple Choices»
Затребованный URI обозначает более одного ресурса. Например, URI может обозначать документ, переведенный на несколько языков.
В теле содержимого, возвращенном сервером, может находиться перечень более конкретных данных о том, как выбрать ресурс правильно.

301=»Moved Permanently» — перемещен навсегда
Затребованный URI уже не используется сервером, и указанная в запросе операция не выполнена.
Новое местонахождение затребованного документа указывается в заголовке Location. Во всех последующих запросах данного документа следует указывать новый URI.
При запросах не методом HEAD сервер должен передать в теле сообщения гипертекстовое пояснение.
При использовании всех методов, кроме GET и POST, предварительно следует уведомить пользователя об изменении ссылки.
Не стоить забывать, что некоторые агенты ошибочно меняют метод POST на GET после перехода на другой адрес.

302=»Moved Temporarily» — временно перемещен
Затребованный URI перемешен, но лишь временно. Заголовок Location указывает на новое местонахождение.
Сразу же после получения этого кода состояния клиент должен разрешить запрос при помощи нового URI, но во всех последующих запросах необходимо пользоваться старым URI.
При всех методах кроме HEAD сервер должен передать в теле гипертекстовое пояснение.
При использовании всех отличных от GET и POST методов предварительно следует уведомить пользователя об изменении URI.
При обращении к следующему ресурсу метод POST на GET менять следует как это делают некоторые агенты.

303=»See Other»
Затребованный URI можно найти по другому URI (указанному в заголовке Location). Его следует выбрать методом GET по данному ресурсу.

304=»Not Modified»
Это код ответа на заголовок lf-Modified-Since, если URI не изменялся с указанной даты. Тело содержимого не посылается, и клиент должен использовать свою локальную копию.

305=»Use Proxy»
Доступ к затребованному URI должен осуществляться через proxy-сервер, указанный в заголовке Location.

306=»(Unused)»

307=»Temporary Redirect»

Запрос клиента является неполным (Client Error 4xx)

Коды ответов в диапазоне 400-499 означают, что запрос клиента неполный. Эти коды могут также означать, что от клиента требуется дополнительная информация.

400=»Bad Request»
Означает, что сервер обнаружил в запросе клиента синтаксическую ошибку.

401=»Unauthorized» — требуется авторизация
Этот код результата, передаваемый с заголовком WWW-Authenticate, показывает, что пославший запрос пользователь не имеет необходимых
полномочий и что при повторении запроса с указанием данного URI пользователь должен такие полномочия предоставить.

402=»Payment Required»
Этот код в HTTP еще не реализован.

403=»Forbidden»
Запрос отклонен по той причине, что сервер не хочет (или не имеет возможности) ответить клиенту.

404=»Not Found» — не найдено
Документ по указанному URI не существует./p>

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»
Сервер не будет обрабатывать запрос, потому что его тело имеет неподдерживаемый формат.

416=»Requested Range Not Satisfiable»
Запрашиваемый диапазон не допустим

417=»Expectation Failed»
Ожидание не удалось

422=»Unprocessable Entity» — сервер успешно принял запрос, может работать с указанным видом данных (например, в теле запроса находится XML-документ, имеющий верный синтаксис),
однако имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом.
В некоторых системах используется для передачи требования дополнительных данных: NOT ENOUGH DATA (не хвататет данных)

429=»You exceeded the rate limit»
Превышен лимит запросов

449=»Retry with a proxy in another country»

450=»Rating Service Unavailable»

451=»Unavailable For Legal Reasons»
Доступ к ресурсу ограничен из-за проблем с законом (451 — Site is not permitted in your country).

452=»Could be site not permitted by employer»

453=»Could be site not permitted by ISP»

460=»Blocked by Repressive Regime»

Ошибки сервера (Server Error 5xx)

Коды ответов в диапазоне 500-599 показывают, что сервер столкнулся с ошибкой и, вероятно, не сможет выполнить запрос клиента.

500=»Internal Server Error»
При обработке запроса на сервере один из его компонентов выдал аварийный отказ или столкнулся с ошибкой конфигурации. Часто бывает связанно с ошибками в файле .htaccess

501=»Not Implemented»
Клиент запросил выполнение действия, которое сервер выполнить не может.

502=»Bad Gateway»
Сервер (или proxy-сервер) получил недопустимые ответы другого сервера (или proxy-сервера).

503=»Service Unavailable»
Данный код означает, что данная служба временно недоступна, но в будущем доступ к ней будет восстановлен.
Если сервер знает, когда это произойдет, может быть также выдан заголовок Retry-After.

504=»Gateway Time-out»
Этот ответ похож на 408 (Request Time-out), за исключением того, что шлюз или уполномоченный сервер превысил лимит времени.

505=»HTTP Version not supported»
Сервер не поддерживает версию протокола HTTP, использованную в запросе.

560=»Server is being censored»

Ошибки ( Error 7xx)

701=»Your ISP is being a twat»

702=»Your organization is being a twat»

703=»Your government is being a twat»

704=»Your ISP is being a twat, and has messed with your DNS request, sending you to a spamvertizement for the domain requested»

705=»Your ISP is throttling / packet shaping the living hell out of your connection»

706=»Variant HTML requested (mobile, Flash-free….lots of flags in here)»

707=»The current server time (in ticks since the epoch) & the server’s time zone»

Ошибки ( Error 9xx)

911=»Internet Emergency. The provider of this connection is being forced to censor this request»

Для отправки кода статуса из PHP используется директива «header Status».

Описание HTTP-кодов на wikipedia.