RuntimeError: Response content shorter than Content-Length

快速结论：该报错通常出现在 Gradio 应用中使用多个 Audio 组件或链式事件（如 .then()、.success()）加载音频文件时，优先排查是否在短时间内多次触发音频加载或使用了带后处理（如 FFmpeg 转码）的下载流程。

问题场景

用户在 Gradio Blocks 应用中大量实例化 gr.Audio 组件（10+），或通过链式事件监听器（.then() / .success()）更新音频输出时，Audio 组件加载新音频变慢或完全失败。复现条件包括：

使用 yt-dlp 下载 YouTube 音频并经过 FFmpeg 后处理生成 WAV 文件后加载。
用户在界面中反复选择或上传音频示例（.wav 文件），浏览器控制台出现大量 pending 的上传请求。
仅使用 gr.Audio(sources="microphone", type="filepath") 的简单测试脚本也能触发，且短音频更容易出现。

报错原文

ERROR:    Exception in ASGI application
RuntimeError: Response content shorter than Content-Length

原因分析

可能原因包括：

链式事件监听（.success() 或 .then()）在多步骤音频传输过程中导致响应体比预期的 Content-Length 短，ASGI 服务器（如 uvicorn）因此抛出异常。
Gradio 的缓存管理问题：每次上传新音频时，Gradio 保留所有临时文件且不清理，导致相同文件重复上传后 Content-Length 与实际流长度不一致。用户反馈 h11._util.LocalProtocolError: Too much data for declared Content-Length 是类似表现。
短音频文件更容易触发该问题（与音频时长、编码有关）。

注意：该 bug 已被标记为确认，但即使在 Gradio 5.38.0 上仍然可复现（2025-09-19 关闭时状态）。核心修复可能仍在开发中。

环境排查

确认 Gradio 版本（Issue 中测试到 5.38.0 仍有问题）
确认 Python 版本（Issue 中为 3.11）
确认操作系统（Windows / Ubuntu 均报告）
确认是否使用 yt-dlp + FFmpeg 后处理或任何音频下载/转码逻辑
检查浏览器控制台是否存在 pending 的上传请求

解决步骤

可优先尝试：避免在同一个音频流上使用链式事件。将 .success() 或 .then() 改为独立的事件监听，如：

retrieve_audio_btn.click(
    _yt_download,
    inputs=[audio_link],
    outputs=[audio_output]
)
audio_output.change(
    lambda v: gr.Audio(value=v),
    inputs=[audio_output],
    outputs=[audio_input]
)

如果无法避免链式调用，尝试在每次加载音频前手动删除旧临时文件（Gradio 默认不清理缓存）。
限制 gr.Audio 组件的数量——减少应用中 Audio 实例到 5 个以下，看是否缓解。
升级到最新 Gradio 版本（Issue 关闭时主分支有相关修复，但 5.38.0 未彻底解决）。
作为临时绕过方案：将音频文件转换为其他格式（如 MP3）再加载，避免 WAV 的大文件体积与短音频的编码问题。

验证方法

使用最小复现代码反复加载新音频（例如连续点击“Retrieve audio”按钮 3-5 次），不再出现 RuntimeError: Response content shorter than Content-Length 即表示问题已缓解。

参考来源

gradio-app/gradio #8878

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

RuntimeError: Response content shorter than Content-Length