Question

使用Django，我从服务器发送pdf文件。如果我使用以下方式将其作为附件发送：

response['Content-Disposition'] = 'attachment; filename=test.pdf'

下载效果很好，但在Chrome控制台中出现错误：

GET http://12.345.678.09/vpas/?print_confirm=true undefined (undefined)

如果我在没有设置响应的Content-Disposition的情况下发送pdf，则没有错误。这个错误的原因是什么，我怎么能摆脱它？

这是http（来自Firefox - 无法从Chrome获取尽可能多的详细信息）：

http://12.345.678.09/vpas/?print_confirm=true&vpa_id_to_print=2355

GET /vpas/?print_confirm=true&vpa_id_to_print=2355 HTTP/1.1
Host: 12.345.678.09
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110420 Firefox/3.6.17 GTB7.1 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cookie: sessionid=fdabaccd2a731fd459cd5d6c3f5004f1
Cache-Control: max-age=0

HTTP/1.1 200 OK
Server: nginx/0.5.33
Date: Mon, 02 May 2011 00:59:48 GMT
Content-Type: application/pdf
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Cookie
Content-Disposition: attachment;
Set-Cookie: sessionid=fdabaccd2a731fd459cd5d6c3f5004f1; expires=Mon, 02-May-2011 01:59:48 GMT; Max-Age=3600; Path=/

这是我可以从Chrome获得的http：

Request URL:http://12.345.678.09/vpas/?print_confirm=true&vpa_id_to_print=2355
Request Headers
Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
User-Agent:Mozilla/5.0 (Windows NT 5.1) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.60 Safari/534.24
Query String Parameters
print_confirm:true
vpa_id_to_print:2355

Answer 1

问题是由Chrome 16遵循正确的RFC标准引起的。

您必须用双引号括起文件名。见http://code.google.com/p/chromium/issues/detail?id=103618

在你的情况下，它会......

response['Content-Disposition'] = 'attachment; filename="test.pdf"'

同样重要的是，您已经使用分号来分隔值而不是逗号。这可能会导致Chrome中出现相同的结果

Answer 2

在最近的Chrome升级后，我刚刚在渲染动态pdf时遇到了这个错误。以前代码在所有浏览器中都运行良好。

我的解决方法是删除文件名中的所有嵌入空格和逗号。可能有其他元字符要删除，但这解决了我的用户的问题。

为了搜索引擎的优势，Chrome中出现了错误：

从服务器收到的重复标头

Error 349 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION)

来自服务器的响应包含重复的标头。此问题通常是配置错误的网站或代理的结果。只有网站或代理管理员才能解决此问题。

Answer 3

if not 'HTTP_USER_AGENT' in request.META or u'WebKit' in request.META['HTTP_USER_AGENT']:
    # Safari 3.0 and Chrome 2.0 accepts UTF-8 encoded string directly.
    filename_header = 'filename=%s' % original_filename.encode('utf-8')
elif u'MSIE' in request.META['HTTP_USER_AGENT']:
    try:
        original_filename.encode('ascii')
    except UnicodeEncodeError:
        original_filename = 'subtitles.' + h.file_type

    filename_header = 'filename=%s' % original_filename
else:
    # For others like Firefox, we follow RFC2231 (encoding extension in HTTP headers).
    filename_header = 'filename*=UTF-8\'\'%s' % iri_to_uri(original_filename.encode('utf-8'))

response['Content-Disposition'] = 'attachment; ' + filename_header

这是文件下载的示例。这是如此复杂，因为不同的浏览器以不同的方式处理“不ascii”名称，这适用于Chrome。

Answer 4

ctrl+shift+j

打开Chrome控制台。

网络将有标题信息。

Answer 5

我认为您的响应中的'transfer-encoding：chunked'HTTP标头会导致此问题。我在ASP .NET Web应用程序上遇到了类似的问题。此处记录了Chrome问题： http://code.google.com/p/chromium/issues/detail?id=83332

尝试使用PDF文件附件的大小设置内容长度标题（以字节为单位）。我对Django一无所知，所以你可能还需要研究一种明确抑制transfer-encoding：chunked头的方法。

我还注意到过早关闭HTTP响应（再次，这是ASP .NET）对Chrome能够打开PDF文件产生了负面影响。

将pdf作为附件发送会导致Chrome浏览器中出现未定义的错误

5 个答案: