Django接收AVR自定义POST在Apache WSGI部署报Unsupported Media Type错误

根本原因说明 #

你碰到的这个问题是嵌入式设备接入Django服务时的高频踩坑点，本质上是runserver开发服务和Apache mod_wsgi生产模式的请求处理逻辑存在两层核心差异：

• runserver默认开启DEBUG模式，生产环境才生效的强校验规则在开发模式下会被跳过，哪怕请求头不规范也能正常流转到视图层处理
• mod_wsgi运行在守护进程模式时，Apache会先对入站请求做一层前置校验，不符合规则的请求会被提前拦截，拦截日志会被归类为WSGI错误输出，很容易把排查方向带偏

可落地的分步修复操作 #

• 第一步：抓包确认真实请求头
  直接在服务器本地抓包，查看AVR设备发往/api/micro/data的POST请求实际携带的Content-Type值：这类嵌入式设备的HTTP协议栈实现通常不严格遵守标准，发送原始字节POST时，可能出现Content-Type为空、为自定义非标准MIME（如application/avr-raw）、为application/octet-stream等非规范值的情况，别靠猜测，抓包获取真实值是排查的基础。
• 第二步：解决Django应用层的MIME校验拦截
  如果抓包确认请求已经正常到达Django进程，就检查对应接口的校验逻辑：
  • 若接口使用Django REST Framework类视图：DRF默认的解析规则仅允许处理application/json、application/x-www-form-urlencoded格式的请求体，碰到不在允许列表内的Content-Type就会直接返回415错误。修复方式：给该视图单独配置解析规则，添加parser_classes = [parsers.BaseParser]，允许接收任意格式的原始请求字节，不需要强制按照指定格式解析内容。
  • 若使用原生Django函数视图：检查是否在自定义中间件、装饰器中添加了MIME类型校验逻辑——这类逻辑通常在DEBUG开启的开发环境下会被临时放行，生产环境DEBUG关闭后就会生效拦截请求，可临时注释对应校验逻辑验证是否为拦截源。
• 第三步：解决Apache/mod_wsgi层的前置拦截
  如果抓包发现请求根本没到达Django进程，就排查Apache侧的配置规则：
  • 检查站点是否开启了mod_security模块：该模块的默认规则会拦截所有不在白名单内的Content-Type请求，可临时关闭该模块的规则测试请求连通性，确认问题后把AVR设备发送的实际Content-Type值加入模块白名单即可。
  • 检查站点配置中的头改写规则：确认没有配置类似ForceType text/plain的规则，把所有请求的Content-Type强制改写为固定值，避免和Django层的校验规则冲突。
• 第四步：兼容空Content-Type的边缘场景
  如果确认设备发送的请求没有携带Content-Type头，不要在Apache层强制补全头值（不同版本mod_wsgi对头的传递存在兼容性差异），直接在Django侧添加轻量中间件：仅匹配/api/micro/data路径的请求，如果检测到CONTENT_TYPE为空，直接默认赋值为application/octet-stream，再把请求流转到视图层处理。

注意：所有规则适配都要限定在/api/micro/data专属接口范围内，不要全局关闭Content-Type校验，避免引入非法请求注入风险。

内容的提问来源于stack exchange，提问作者Hamzeh