Sending pdf as attachment causes undefined error in Chrome browser

Using Django, I am sending a pdf file from the server. If I send it as an attachment using:

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

it downloads fine, but in the Chrome console there is an error:

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

If I send the pdf without setting the Content-Disposition of the response, there is no error. What is the cause of this error and how can I get rid of it?

This is the http (from Firefox - couldn't get as many details from 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=/

This is the http I could get from Chrome:

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开发者_Go百科.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

The issue is caused by Chrome 16 following the correct RFC standard.

You have to surround the file name with double quotes. See http://code.google.com/p/chromium/issues/detail?id=103618

In your case, it would be ...

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

Also important, which you've done already, using semi-colons to separate the values rather than commas. This could cause the same outcome in Chrome

I just encountered this error today in rendering dynamic pdfs, after a recent Chrome upgrade. Previously the code had worked fine in all browsers.

My work-around was to remove any embedded spaces and commas in the filename. There may be other meta characters to remove, but this fixed the problem for my users.

For the benefit of the search engines, the error appearing in Chrome:

Duplicate headers received from server

Error 349 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION)

The response from the server contained duplicate headers. This problem is generally the result of a misconfigured website or proxy. Only the website or proxy administrator can fix this issue.

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

This is example for file downloading. It is so complex because different browsers handle "not ascii" names in different ways and this is working for Chrome.

I think that the 'transfer-encoding: chunked' HTTP header in your response is causing the issue. I had a similar issue on an ASP .NET web application. The Chrome issue is documented here: http://code.google.com/p/chromium/issues/detail?id=83332

Try setting a content-length header with the size of the PDF file attachment in bytes. I don't know anything about Django, so you might also need to look into a way to explicitly suppress the transfer-encoding: chunked header as well.

I also noticed that prematurely closing the HTTP response (again, this was ASP .NET) had an adverse impact on Chrome being able to open the PDF file.

ctrl+shift+j

opens up the chrome console.

network will have the header info.