415 是什么
415 Unsupported Media Type 表示服务端无法处理请求携带的内容类型：可能是完全没带 Content-Type，可能是类型拼错或大小写不规范，也可能是服务端确实不支持该媒体类型（比如只收 JSON 却收到 XML）。它和 400 的区别在于：报文本身能被解析，问题出在「这段内容用什么格式表达」上。
基本信息
| 名称与状态码 | 415 Unsupported Media Type |
|---|---|
| 语义 | 服务端不支持请求体的媒体类型 |
| 规范 | RFC 9110 §15.5.16 |
| 相关头 | Content-Type、Accept、Accept-Post（新版接口惯例） |
| 常见触发 | 缺少 Content-Type、类型拼写错误、上传文件类型不受支持 |
| 与 400 区别 | 400 表示报文无法解析，415 表示类型不被接受 |
典型使用场景
- 接口调试：POST JSON 却忘了带 Content-Type，服务端按表单解析失败
- 接口契约收敛：明确只接受 application/json，其他类型统一 415 并给出提示
- 文件上传接口：限定允许的 MIME 类型，拒绝可执行文件与非常规格式
- 排查 PATCH 请求失败：用 application/json 而非补丁专用类型时会被拒绝
- 网关策略：在入口层统一拦截不支持的媒体类型，减轻后端压力
常见错误与修正
常见错误与修正
# 错误示范：带了 JSON 但没声明 Content-Type（默认按表单处理）
curl -X POST https://api.example.com/users -d '{"name":"a"}'
# 修正：显式声明 JSON
curl -X POST https://api.example.com/users \
-H 'Content-Type: application/json' \
-d '{"name":"a"}'
# 排查时先看服务端接受什么类型
curl -sI https://api.example.com/users | grep -i -E 'accept|allow'
# 上传文件时明确类型
curl -X PUT --data-binary @report.pdf -H 'Content-Type: application/pdf' https://api.example.com/files/report.pdf常见触发与处理
| 现象 | 原因 | 处理方式 |
|---|---|---|
| POST JSON 返回 415 | 缺少或错误的 Content-Type | 补上 application/json 后重试 |
| 写成 Application/Json | 类型标记大小写不规范 | 按规范的媒体类型小写写法提交 |
| multipart 上传失败 | boundary 缺失或文件名含特殊字符 | 由客户端库自动生成 boundary |
| PATCH 被拒 | 用 application/json 而非补丁媒体类型 | 改用服务端声明支持的补丁类型 |
| 老设备上传被拒 | 服务端不接受该 MIME 类型 | 转换为受支持的格式后再上传 |
媒体类型按规范是不区分大小写的，但现实中不少框架用精确字符串比较，写错大小写或加多余空格都会被直接拒绝。排查时优先与服务端声明的支持列表逐字比对。
不能用 Content-Type 作为唯一的安全边界：上传接口若只校验类型不校验内容与后缀，攻击者仍可把可执行内容伪装成图片类型上传；服务端应以实际内容嗅探与扩展名白名单为准。