Geek Answers Handbook

Sending PDF as an attachment results in undefined error in Chrome browser

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

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

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

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

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

This is http (from Firefox - cannot get so 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 can 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.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
+4
source share
5 answers

The problem is that Chrome 16 complies with the correct RFC standard.

You must surround the file name with double quotation marks. See http://code.google.com/p/chromium/issues/detail?id=103618

In your case it will be ...

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

It is also important that you have already done using half-columns to separate values, not commas. This could lead to the same outcome in Chrome.

+12
source

I just ran into this error today when rendering dynamic pdf files after a recent Chrome update. Previously, the code worked fine in all browsers.

My workflow was to remove any embedded spaces and commas in the file name. There may be other metacharacters to delete, but this fixes the problem for my users.

In the interest of search engines, an error that appears in Chrome:

Duplicate headers received from the server

 Error 349 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION)

The response from the server contained duplicate headers. This problem is usually the result of an improperly configured website or proxy. Only a website or proxy administrator can fix this problem.

+2
source 
 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 an example of uploading files. This is so complicated because different browsers handle non ascii names differently and this works for Chrome.

0
source 
 ctrl+shift+j

opens the chrome console.

the network will have header information.

0
source

I think the HTTP transfer-coding: chunked header in your answer is causing the problem. I had a similar problem in an ASP.NET web application. The Chrome issue is described here: http://code.google.com/p/chromium/issues/detail?id=83332

Try customizing the 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 learn how to explicitly exclude the transfer encoding: chunked.

I also noticed that closing the HTTP response prematurely (again, it was ASP.NET) negatively impacted that Chrome could open the PDF file.

0
source

More articles:


All Articles