PrepBro
← Назад к вопросам

Приведи примеры 400-х ошибок

1.6 Junior🔥 141 комментариев
#Браузер и сетевые технологии

Комментарии (1)

🐱
deepseek-v3.2PrepBro AI6 апр. 2026 г.(ред.)

Ответ сгенерирован нейросетью и может содержать ошибки

Примеры клиентских ошибок 4xx

Клиентские ошибки 4xx (400-499) в протоколе HTTP указывают, что проблема возникла на стороне клиента (браузера или другого пользовательского агента). Эти ошибки сигнализируют о некорректных запросах, проблемах с авторизацией, доступом или конфликтах ресурсов. Важно правильно их обрабатывать для улучшения UX и безопасности приложения.

1. 400 Bad Request

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

  • Пример ситуации: Клиент отправляет JSON с синтаксической ошибкой (например, пропущена кавычка).
  • Пример запроса и ответа: 
    // Некорректный запрос (POST /api/user)
POST /api/user HTTP/1.1
Content-Type: application/json

{"name": "John", "age": 30 // ошибка: нет закрывающей фигурной скобки

    // Ответ сервера
HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error": "Invalid JSON syntax"}

    **Практический совет на Frontend**: Всегда валидируйте данные перед отправкой и обрабатывайте ответ `400`, чтобы показать пользователю понятное сообщение об ошибке (например, "Проверьте правильность заполненных данных").

2. 401 Unauthorized

Ошибка аутентификации. Запрос требует аутентификации пользователя, но она не предоставлена или не прошла проверку.

  • Пример ситуации: Попытка доступа к защищённому API-эндпоинту без токена или с истёкшим/невалидным токеном.
  • Пример ответа: 
    HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="Access to the API", error="invalid_token"

    **Практический совет на Frontend**: При получении `401`:
    1.  Перенаправьте пользователя на страницу входа.
    2.  Очистите невалидные токены из `localStorage`/`sessionStorage`.
    3.  Возможно, реализуйте автоматическое обновление токена, если у вас настроен механизм refresh-токенов.

3. 403 Forbidden

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

  • Пример ситуации: Пользователь с ролью editor пытается удалить статью, на что имеет право только admin.
  • Пример ответа: 
    HTTP/1.1 403 Forbidden
Content-Type: application/json

{"error": "You do not have permission to delete this resource"}

    **Практический совет на Frontend**: Лучше не допускать появления такой ситуации, скрывая или деактивируя UI-элементы (кнопки, ссылки) для действий, которые запрещены на уровне ролей пользователя. Если же `403` пришёл, покажите понятное сообщение типа "У вас недостаточно прав".

4. 404 Not Found

Самый известный статус. Сервер не может найти запрошенный ресурс (URL).

  • Пример ситуации: Пользователь перешёл по битой ссылке /articles/old-article-that-was-deleted.
  • Пример ответа: 
    HTTP/1.1 404 Not Found
Content-Type: text/html

<!DOCTYPE html>
<html>
<body>
    <h1>Страница не найдена</h1>
    <p>Запрошенный URL не существует.</p>
</body>
</html>

    **Практический совет на Frontend**:
    *   Создайте кастомную страницу `404` с навигацией по сайту.
    *   В **SPA** (React, Vue, Angular) настройте "catch-all" роут для отображения такого компонента.
    *   **В коде**:

    ```javascript
    // React Router v6
    import { Routes, Route } from 'react-router-dom';
    import NotFoundPage from './NotFoundPage';

    function App() {
      return (
        <Routes>
          <Route path="/" element={<Home />} />
          <Route path="/about" element={<About />} />
          <Route path="*" element={<NotFoundPage />} /> {/* Обработка 404 */}
        </Routes>
      );
    }
    ```

5. 405 Method Not Allowed

Недопустимый метод HTTP. Ресурс существует, но для него не поддерживается используемый метод.

  • Пример ситуации: Отправка POST-запроса на эндпоинт /api/users, который поддерживает только GET для получения списка.
  • Пример ответа (с указанием разрешённых методов): 
    HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

    **Практический совет на Frontend**: Обычно эта ошибка возникает из-за логической ошибки в коде. Проверьте, правильно ли вы указываете HTTP-метод (`GET`, `POST`, `PUT`, `DELETE`) при вызове API.

6. 409 Conflict

Конфликт состояния ресурса. Запрос конфликтует с текущим состоянием сервера (часто при операциях обновления).

  • Пример ситуации:
    1.  **Оптимистичная блокировка**: Два пользователя одновременно пытаются отредактировать один документ. Сервер возвращает `409` второму, так как версия документа (ETag) уже изменилась.
    2.  **Создание дублирующего ресурса**: Попытка создать пользователя с уже существующим email.
  • Пример ответа: 
    HTTP/1.1 409 Conflict
Content-Type: application/json

{"error": "User with this email already exists"}

    **Практический совет на Frontend**: Обработайте эту ошибку, предложив пользователю актуальные данные и возможность повторно отправить запрос (например, после обновления формы).

7. 429 Too Many Requests

Превышение лимита запросов (Rate Limiting). Пользователь отправил слишком много запросов за короткий промежуток времени.

  • Пример ситуации: Сработал механизм защиты от DDoS или лимит вызовов публичного API.
  • Пример ответа (часто с заголовками, указывающими время ожидания): 
    HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0

    **Практический совет на Frontend**:
    *   Проанализируйте заголовки ответа (`Retry-After`, `X-RateLimit-*`).
    *   Реализуйте экспоненциальную задержку (exponential backoff) при повторных вызовах API.
    *   Покажите пользователю понятное сообщение: "Слишком много запросов. Попробуйте через 1 минуту."

Другие распространённые ошибки 4xx

  • 402 Payment Required – Зарезервировано для будущего использования (платёжные системы).
  • 408 Request Timeout – Сервер не дождался полного запроса от клиента в отведённое время.
  • 415 Unsupported Media Type – Сервер отказывается обработать запрос, потому что формат данных (Content-Type) не поддерживается. Например, отправка XML вместо ожидаемого JSON.
  • 422 Unprocessable Entity (WebDAV) – Запрос семантически корректен, но содержит логические ошибки (часто используется для валидации данных, например, в API Rails).

Заключение для Frontend-разработчика

Понимание и корректная обработка ошибок 4xx — критически важный навык.

  • Всегда обрабатывайте ошибки в catch-блоках try/catch, в методах .catch() промисов или перехватчиках в библиотеках (axios.interceptors).
  • Предоставляйте пользователю ясную обратную связь, не ограничиваясь консолью.
  • Логируйте эти ошибки (с контекстом запроса) для анализа проблем пользователей.
  • Правильная обработка повышает отказоустойчивость приложения и качество пользовательского опыта (UX).
Приведи примеры 400-х ошибок | PrepBro