Sending pdf as attachment causes undefined error in Chrome browser
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_filenameelse: # 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.