Где прописывается Content-Type в HTTP-запросе
Что проверяют
Понимаете ли вы устройство HTTP-сообщения (стартовая строка, заголовки, пустая строка, тело) и умеете ли найти и подменить заголовок в своих инструментах. Следом обычно спрашивают, чем Content-Type отличается от Accept и что сервер должен вернуть на неверный тип.
Как отвечать
Content-Type прописывается в блоке заголовков: после строки вида POST /api/users HTTP/1.1 и до пустой строки, за которой идёт тело. Он описывает формат тела запроса, например Content-Type: application/json; charset=utf-8. Если тела нет, как у обычного GET, заголовок не нужен.
Самые частые значения:
application/json: REST API;application/x-www-form-urlencoded: классическая HTML-форма, тело видаname=Ivan&age=30;multipart/form-data: форма с файлами, обязателен параметрboundary, по которому сервер режет тело на части;text/plain,application/xml,application/octet-stream: текст, XML и произвольные байты.
Где это видно на практике. В Postman на вкладке Headers, причём при выборе Body → raw → JSON заголовок подставляется сам. В DevTools браузера: Network, нужный запрос, Request Headers. В curl: -H "Content-Type: application/json", а флаг -d без явного заголовка отправит application/x-www-form-urlencoded. В ответе сервера тоже есть Content-Type, но он описывает уже тело ответа.
Для тестировщика это источник негативных проверок: запрос без заголовка, с неверным типом, с неподдерживаемой кодировкой. Корректный сервер отвечает 415 Unsupported Media Type или 400, а не падает с 500.
Где спотыкаются
Путают Content-Type и Accept. Первый сообщает, что лежит в теле запроса, второй просит сервер вернуть ответ в нужном формате.
Вручную прописывают multipart/form-data в Postman или в коде автотеста. Без boundary сервер не разберёт тело, а клиент, если заголовок не трогать, сгенерирует его сам.
Не знают, что fetch со строкой в body по умолчанию шлёт text/plain;charset=UTF-8. Тело выглядит как JSON, бэкенд его отвергает, и это легко завести как баг сервера.