Отправка pdf в виде вложения вызывает неопределенную ошибку в браузере Chrome - PullRequest
4 голосов
/ 30 апреля 2011

Используя Django, я отправляю файл pdf с сервера.Если я отправляю его в виде вложения, используя:

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

, он загружается нормально, но в консоли Chrome возникает ошибка:

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

Если я отправляю 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=/

Это http, который я мог получить от 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

Ответы [ 5 ]

12 голосов
/ 21 марта 2012

Проблема вызвана тем, что Chrome 16 придерживается правильного стандарта RFC.

Вы должны заключить имя файла в двойные кавычки. Смотри http://code.google.com/p/chromium/issues/detail?id=103618

В вашем случае это было бы ...

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

Также важно, что вы уже сделали, используя точки с запятой для разделения значений, а не запятых. Это может привести к тому же результату в Chrome

2 голосов
/ 01 февраля 2012

Я только что столкнулся с этой ошибкой сегодня при рендеринге динамических PDF-файлов после недавнего обновления Chrome. Ранее код работал нормально во всех браузерах.

Мой обходной путь должен был удалить все встроенные пробелы и запятые в имени файла. Могут быть удалены другие метасимволы, но это устранило проблему для моих пользователей.

Для поисковых систем ошибка, появляющаяся в Chrome:

Повторяющиеся заголовки, полученные от сервера

Error 349 (net::ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION)

Ответ от сервера содержал дублирующиеся заголовки. Эта проблема обычно является результатом неправильно настроенного веб-сайта или прокси-сервера. Только администратор веб-сайта или прокси-сервера может решить эту проблему.

0 голосов
/ 13 июня 2011
ctrl+shift+j

открывает хромированную консоль.

сеть будет иметь информацию заголовка.

0 голосов
/ 03 января 2012

Я думаю, что HTTP-заголовок 'Transfer-Encoding: Chunked' в вашем ответе вызывает проблему. У меня была похожая проблема в веб-приложении ASP .NET. Проблема Chrome описана здесь: http://code.google.com/p/chromium/issues/detail?id=83332

Попробуйте установить заголовок длины содержимого с размером вложения файла PDF в байтах. Я ничего не знаю о Django, поэтому вам также может понадобиться найти способ явного подавления кодировки передачи: также заголовка chunked.

Я также заметил, что преждевременное закрытие HTTP-ответа (опять-таки это ASP .NET) отрицательно сказалось на возможности Chrome открывать файл PDF.

0 голосов
/ 30 апреля 2011
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.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...