Ошибка 415 Unsupported Media Type

HTTP 415 Unsupported Media Type означает, что сервер отказывается принять содержимое запроса из-за неподдерживаемого формата представления. Чаще всего причина находится в Content-Type, реальном формате body, charset, multipart boundary или Content-Encoding.

Типичный сценарий: endpoint ожидает JSON, а клиент отправляет form data или указывает Content-Type: application/json, хотя тело фактически не является JSON.

Что означает HTTP 415

клиент
  ↓ Content-Type + body
сервер
  ↓
поддерживает этот media type?
  ├─ нет → 415
  └─ да → parsing / validation

RFC 9110 связывает 415 с неподдерживаемым форматом содержимого запроса. Причиной может быть как Content-Type, так и Content-Encoding либо фактическая обработка содержимого.

415, 400 и 422

См. также: Ошибка 400 Bad Request и Ошибка 422 Unprocessable Content.

Причина 1. Неверный Content-Type

Endpoint ожидает:

Content-Type: application/json

а клиент отправляет:

Content-Type: text/plain

Даже если body визуально похож на JSON, сервер может корректно отклонить запрос.

Причина 2. Заголовок говорит JSON, но body другой

Плохой запрос:

Content-Type: application/json

name=Ivan&enabled=true

Header и содержимое противоречат друг другу.

Причина 3. Multipart сформирован неправильно

Для multipart/form-data boundary является частью Content-Type:

Content-Type: multipart/form-data; boundary=----ExampleBoundary

При использовании curl не стоит вручную задавать multipart Content-Type, если -F может корректно сформировать boundary сам.

curl -i -F 'file=@photo.webp' https://example.com/upload

Причина 4. Неподдерживаемый Content-Encoding

Если клиент отправил закодированное содержимое, которое сервер не умеет декодировать, 415 также может быть релевантным ответом.

Поэтому проверяйте не только Content-Type, но и:

Content-Encoding: gzip

Шаг 1. Сохраните request и response headers

curl -i \
  -H 'Content-Type: application/json' \
  --data-binary @request.json \
  https://api.example.com/v1/items

Зафиксируйте:

• method;
• URL;
• Content-Type;
• Content-Encoding;
• response body;
• request ID.

Шаг 2. Проверьте реальный body

Для JSON:

jq . request.json

Если JSON не разбирается, проблема уже не только в media type. Если JSON валиден, но сервер всё равно отдаёт 415, сравните header с API contract.

Шаг 3. Сравните запрос с минимальным рабочим примером

Начните с самого простого request:

curl -i \
  -H 'Content-Type: application/json' \
  -d '{"name":"test"}' \
  https://api.example.com/v1/items

Затем добавляйте отличия клиента по одному.

Так можно отделить проблему формата от авторизации, validation и бизнес-логики.

Шаг 4. Проверьте документацию endpoint

Важно знать точный контракт:

POST /v1/import
Consumes: application/json

или:

POST /v1/upload
Consumes: multipart/form-data

Не делайте вывод только из того, что соседний endpoint принимает JSON.

Шаг 5. Проверьте proxy и gateway

Иногда application поддерживает media type, но gateway policy разрешает только ограниченный набор.

Сопоставьте:

public request → 415
internal request → 2xx

Если это воспроизводится, проверяйте API gateway/WAF/proxy rules.

Шаг 6. Проверьте charset аккуратно

Media type может содержать параметры:

Content-Type: application/json; charset=UTF-8

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

415 после релиза

Частые изменения:

1. frontend переключился с JSON на FormData;
2. SDK начал задавать другой header;
3. backend перестал принимать legacy media type;
4. gateway policy стала строже;
5. появился Content-Encoding;
6. изменился multipart upload.

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

Как проверить исправление

Нужен позитивный и негативный сценарий:

поддерживаемый Content-Type → обработка запроса
неподдерживаемый Content-Type → 415
валидный JSON с неверными значениями → не маскируется под 415

Так вы проверяете не только исчезновение ошибки, но и сохранение корректного API-контракта.

Автоматический мониторинг

Если критичный API принимает JSON, монитор должен отправлять реальный поддерживаемый Content-Type и валидное тело, а не только делать GET на тот же hostname.

UpWatch можно использовать для регулярной проверки API endpoint с заданным методом, body и ожидаемым ответом, если запрос безопасен для периодического выполнения.

Типичные ошибки

• менять JSON body, не проверив Content-Type;
• вручную задавать multipart boundary;
• путать 415 и 422;
• считать 415 сетевой ошибкой;
• забывать Content-Encoding;
• смотреть только backend, когда формат блокирует gateway;
• после исправления принимать любой media type без проверки.

Практический чек-лист

1. Подтвердить HTTP 415.
2. Зафиксировать method и URL.
3. Сохранить Content-Type.
4. Проверить реальный body.
5. Проверить Content-Encoding.
6. Сверить API contract.
7. Воспроизвести минимальным curl.
8. Проверить multipart boundary.
9. Проверить gateway/proxy.
10. Сравнить старый и новый client request.
11. Проверить позитивный media type.
12. Проверить негативный media type после исправления.

Источники и спецификации

• RFC 9110: 415 Unsupported Media Type
• MDN: 415 Unsupported Media Type
• curl: официальная документация