Django 1.11与mod_wsgi 3.5分块响应异常问题咨询

我之前也碰到过类似的情况，你遇到的核心问题是mod_wsgi 3.5搭配Apache时的默认缓冲机制，把你的流式响应给“攒”起来了，直到整个生成器跑完才一次性发送，完全抵消了StreamingHttpResponse的分块传输作用。WSGI规范本身是支持分块响应的，但mod_wsgi的版本特性和Apache的配置会触发这种“强制缓冲”的行为。

下面是一步步的解决思路：

1. 切换mod_wsgi到守护进程模式 #

mod_wsgi的嵌入模式（默认）下，Apache会强制缓冲所有响应内容，根本没机会流式传输。必须把应用放到独立的守护进程里跑，修改Apache配置：

WSGIDaemonProcess myapp processes=2 threads=15 display-name=%{GROUP}
WSGIProcessGroup myapp

把myapp换成你的应用标识，这样mod_wsgi就能独立处理响应，不受Apache的缓冲限制。

2. 关闭mod_wsgi的内部缓冲 #

在你的Django视图里，给StreamingHttpResponse加上mod_wsgi.sendfile的响应头，强制关闭mod_wsgi的sendfile缓冲机制——这个机制会默认把内容攒够一定量再发送：

from django.http import StreamingHttpResponse

def slow_stream_view(request):
    def generate_chunks():
        # 这里是你的慢生成逻辑，比如逐个生成小分块
        for data in your_slow_data_source():
            yield data.encode('utf-8')
    
    response = StreamingHttpResponse(generate_chunks())
    # 关键：禁用mod_wsgi的sendfile缓冲
    response['mod_wsgi.sendfile'] = '0'
    return response

3. 让Apache别插手缓冲 #

Apache的一些模块（比如mod_deflate）会为了压缩内容而缓冲整个响应，这完全破坏流式传输。你需要在虚拟主机配置里禁用这些行为：

# 全局禁用gzip压缩（如果不需要的话）
SetEnv no-gzip 1
SetEnv dont-vary 1

# 或者只针对你的流式视图路径禁用
<Location /your-streaming-endpoint>
    SetEnv no-gzip 1
</Location>

如果你的Apache启用了mod_deflate，一定要确保它不会处理你的流式请求路径。

4. 检查响应头的“坑” #

• 确保响应里没有Content-Length头：Django的StreamingHttpResponse默认不会加，但如果有中间件（比如某些缓存中间件）偷偷加上了，Apache就会认为是完整响应而缓冲。检查你的中间件列表，移除会添加这个头的组件。
• 显式设置分块传输头：可以在视图里加上response['Transfer-Encoding'] = 'chunked'，明确告诉Apache和客户端这是分块响应。

额外小贴士 #

• mod_wsgi 3.5确实有点老了，能升级到4.x版本的话，对流式响应的支持会更完善，少踩很多版本兼容的坑。
• 生成的分块别太小（比如至少几百字节），过小的分块不仅增加网络开销，有些Apache版本还会自动合并它们，达不到你避免超时的目的。
• 确保你的生成器逻辑稳定，别中途抛出异常——一旦生成器断了，mod_wsgi会直接终止响应，反而会导致超时。

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