Ваш конспект

Основы HTTP: ключевые концепции для разработчиков

Ключевые тезисы

• Понимание HTTP критически важно для разработчиков (бэкенд, фронтенд, DevOps) для создания безопасных и корректных API.
• Частые ошибки связаны с неверной трактовкой статус-кодов и методов запросов.
• Безопасность (CORS, куки, уязвимости) — ответственность в первую очередь бэкенд-разработчика.
• Следование стандартам HTTP упрощает интеграцию и предотвращает множество проблем.

Аутентификация vs. Авторизация: статус-коды 401 и 403

• 401 Unauthorized: Сервер не понял, кто вы. Пользователь не предоставил аутентификационные данные (токен, сессию).

  • Пример: Истёкший токен в браузере при попытке запроса новой страницы.

• 403 Forbidden: Сервер понял, кто вы, но доступ запрещён. У пользователя нет прав на доступ к ресурсу.

  • Пример: Обычный пользователь пытается получить доступ к админ-панели.

Резюме: 401 — «Я не знаю тебя», 403 — «Я знаю тебя, но тебе сюда нельзя».

Методы запросов: POST, PUT, PATCH

• POST — для создания новой сущности (пост, комментарий, платёж). Идентификатор (ID) ещё неизвестен.
• PUT — для полного обновления существующей сущности. Требуется передать все поля, даже если меняется одно.
• PATCH — для частичного обновления сущности. Передаются только изменяемые поля.
  • Преимущества PATCH: меньше данных в сети, ниже риск случайной перезаписи.

Важно: Это соглашения. Нарушать их технически можно, но это усложнит понимание кода другими разработчиками.

Куки vs. Заголовки (Headers)

• Куки — это специальные HTTP-заголовки (Set-Cookie), но с ключевой особенностью:
  • Браузер автоматически сохраняет их и отправляет с каждым последующим запросом к домену.
  • Фронтенд-разработчику не нужно вручную управлять их отправкой.
• Обычные заголовки (например, Authorization с токеном) нужно хранить (в памяти, localStorage) и вручную добавлять к каждому запросу.

Безопасность кук: ключевые флаги

Ответственность лежит на бэкенд-разработчике, который устанавливает параметры куки:

1. Secure — кука передаётся только по HTTPS.
2. HttpOnly — кука недоступна из JavaScript. Защищает от XSS-атак (кражи кук через внедрённый JS-код).
3. SameSite — контролирует отправку кук при междоменных (cross-site) запросах.
   • Strict — куки никогда не отправляются с межсайтовых запросов.
   • Lax (рекомендуется) — куки отправляются только с безопасными (GET) межсайтовыми запросами.
   • None — куки отправляются со всеми запросами (опасно, требует Secure).

SameSite защищает от CSRF-атак (Cross-Site Request Forgery).

CORS (Cross-Origin Resource Sharing)

• Проблема: Браузер по умолчанию блокирует запросы с одного домена (origin) к API на другом домене.
• Решение: Бэкенд должен явно разрешить запросы с определённых доменов, отправляя заголовок Access-Control-Allow-Origin.
  • Пример: Бэкенд api.example.com разрешает запросы только с frontend.example.com.
• Важно: CORS — это защита браузера. Запросы из скриптов (Python, cURL) не подвержены CORS.

Распространённые уязвимости, связанные с HTTP

• XSS (Cross-Site Scripting): Внедрение и выполнение вредоносного JavaScript-кода на странице сайта (например, через невалидируемый комментарий). Может привести к краже данных.
• CSRF (Cross-Site Request Forgery): Заставить браузер авторизованного пользователя выполнить нежелательный запрос на целевой сайт. Защита: правильная настройка SameSite у кук и/или CSRF-токены.
• Открытые редиректы (Open Redirect): Если сайт перенаправляет пользователя на URL, указанный в параметре запроса, без валидации, злоумышленник может перенаправить жертву на фишинговый сайт.
• Небезопасная настройка CORS: Разрешение запросов с любых доменов (*) может открыть API для злоупотреблений.

Rate Limiting (Ограничение запросов) и статус 429

• 429 Too Many Requests — статус-код для ограничения частоты запросов.
• Может возвращаться:
  • Веб-сервером (Nginx) на уровне IP-адреса.
  • Бэкенд-приложением согласно бизнес-логике (например, не более 3 отчётов в минуту по тарифу).
• Фронтенд должен обрабатывать этот статус, информируя пользователя о превышении лимита.

Передача файлов

1. multipart/form-data:
   • Самый популярный способ.
   • Позволяет передавать и файлы, и обычные поля формы в одном запросе.
   • Фреймворки часто загружают файл целиком в память/на диск перед обработкой.
2. application/octet-stream:
   • Передача только бинарного файла (без дополнительных полей).
   • Подходит для стриминга больших файлов: данные можно обрабатывать чанками, не загружая файл целиком.
3. Base64 (костыльный способ):
   • Кодирование файла в строку.
   • Недостатки: увеличивает размер на 30-50%, требует дополнительной логики декодирования на бэкенде.

Кэширование на стороне клиента

• Управляется HTTP-заголовками, которые устанавливает бэкенд-разработчик.
• Основной заголовок — Cache-Control.
  • max-age=<seconds> — время жизни кэша в секундах (например, для статических словарей).
  • public / private — можно ли кэшировать ответ на публичных CDN.
  • no-store — запрет на кэширование.
• Преимущество: Браузер (или мобильное приложение) сохраняет данные локально и не делает лишних запросов при повторных обращениях.

Статус-коды успешного выполнения: 200, 201, 204

• 200 OK — универсальный код успеха, возвращается с телом ответа.
• 201 Created — рекомендуется возвращать при успешном создании сущности (обычно после POST). На практике часто используют 200.
• 204 No Content — запрос выполнен успешно, но возвращать тело ответа нечего (например, после успешного DELETE).
  • Идея: Экономия трафика — не отправлять лишние JSON-обёртки ({“success”: true}), если статус и так говорит об успехе.

Выводы

• Чёткое понимание разницы между 401 и 403, POST, PUT и PATCH — обязательный минимум.
• Безопасность (CORS, флаги кук) закладывается на бэкенде.
• Следование стандартам HTTP (даже в мелочах вроде статус-кодов) делает API предсказуемым и снижает риски.