Django 2.0.2中WeasyPrint生成PDF，Firefox忽略inline自动下载求助

我之前在使用Django + WeasyPrint处理PDF预览时也碰到过Firefox这个“顽固”的自动下载问题，明明设置了inline参数却不生效，折腾了一阵终于找到几个靠谱的解决方案，分享给你：

1. 确保正确设置Content-Type响应头 #

Firefox对PDF的inline渲染完全依赖正确的MIME类型，WeasyPrint有时候可能没自动设置，或者被Django中间件意外覆盖，所以必须在响应里明确指定：

response = HttpResponse(content_type='application/pdf')

这一步是核心前提，如果Content-Type不是application/pdf，Firefox会直接触发下载，根本不会理会inline参数。

2. 使用RFC 5987标准的文件名格式 #

Firefox对传统的filename参数处理偶尔会有兼容性问题，尤其是文件名包含特殊字符时，改用UTF-8编码的filename*格式可以彻底解决这个问题：

response['Content-Disposition'] = 'inline; filename*=UTF-8''gene_detail_description_print.pdf'

注意这里的格式：filename*=UTF-8''后面直接跟文件名，中间没有空格，这是RFC 5987规定的标准写法，能让Firefox正确识别文件名的同时，保留inline预览的行为。

3. 检查中间件是否篡改响应头 #

有些Django中间件（比如安全中间件、压缩中间件）可能会悄悄修改你的响应头，导致Content-Disposition或Content-Type被覆盖。你可以：

• 暂时禁用可疑中间件，测试PDF是否能正常inline显示
• 在view函数里把响应头设置放在生成PDF之后，确保你的设置优先级最高

4. 验证实际返回的响应头 #

用Firefox的开发者工具（按F12 → 切换到「网络」标签）查看请求的响应头，确认：

• Content-Type确实是application/pdf
• Content-Disposition正确显示为你设置的inline; filename*=UTF-8''gene_detail_description_print.pdf
  如果这里显示的头和你代码里设置的不一致，说明中间件或者WeasyPrint的内部逻辑在修改它，需要针对性调整。

完整示例代码 #

from django.shortcuts import render_to_string
from django.http import HttpResponse
from weasyprint import HTML

def gene_detail_print_view(request):
    # 渲染PDF对应的HTML模板
    html_content = render_to_string('gene_detail_print.html', {'some_context': 'value'})
    
    # 初始化响应，指定正确的Content-Type
    response = HttpResponse(content_type='application/pdf')
    
    # 使用标准格式设置Content-Disposition
    response['Content-Disposition'] = 'inline; filename*=UTF-8''gene_detail_description_print.pdf'
    
    # 生成PDF并写入响应
    HTML(string=html_content).write_pdf(response)
    
    return response

补充说明 #

如果用户的Firefox手动设置了“总是下载PDF文件”（在设置→应用→PDF文件里），那我们的代码也无法强制inline，但这个是用户端设置，我们要保证的是默认设置下的兼容性。

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