Предотвращение добавления Tomcat кодировки к типам двоичного контента

У нас есть служба на основе Restlet, которая возвращает следующий ответ:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1, Restlet-Framework/2.0.7
X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0
Content-Disposition: inline; filename=Time_for_a_breather.pdf
Date: Fri, 13 May 2011 23:41:24 GMT
Accept-Ranges: bytes
Content-Type: application/pdf;charset=UTF-8
Content-Length: 218495

но, к сожалению, в некоторых браузерах (в частности, в Chrome) у нас возникают проблемы с просмотром pdf.

Из экспериментов и исследований видно, что проблема связана с тем, что jBoss/Tomcat добавляет charset=UTF-8 к типу контента, что заставляет браузер чувствовать, что он получает текстовые данные, а не двоичные данные.

Кто-нибудь знает, как предотвратить добавление jBoss/Tomcat кодировки к типу контента для двоичных данных?


servlets tomcat restlet
person djsnowsill    schedule 13.05.2011    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Контейнер сервлетов делает это только тогда, когда у вас есть

response.setCharacterEncoding("UTF-8");

где-то в вашем коде. См. также javadoc< /а>. Установка кодировки символов не имеет смысла для двоичных данных, поэтому просто не делайте этого при запросах двоичных данных.

person BalusC    schedule 14.05.2011

arrow_upward
1
arrow_downward

В моем случае это оказался Spring CharacterEncodingFilter. Если вы установите forceEncoding в true, он добавит кодировку символов к типу содержимого, даже если это не имеет смысла для двоичных данных.

Чтобы исправить это, установите forceEncoding на false или оставьте значение по умолчанию. И проверьте эффект, который он имеет, например. в ответах JSON.

person Codo    schedule 05.03.2015

arrow_upward
0
arrow_downward

На данном этапе мне не удалось остановить Tomcat от добавления charset=UTF-8 к заголовку Content-Type, из-за чего Chrome PDFViewer (внутренняя программа просмотра PDF) не может просмотреть PDF-документ.

Экспериментируя, я обнаружил, что если я не верну Content-Length и не установлю Transfer-Encoding=chunked, то PDF-файл будет доступен для просмотра Chrome PDFViewer. На данный момент это обходной путь, но, вероятно, хрупкое решение.

person djsnowsill    schedule 14.05.2011
comment
На самом деле, это кодировка ответа по умолчанию, когда вы не устанавливаете заголовок Content-Length. Вам не нужно явно устанавливать заголовок Transfer-Encoding самостоятельно. - person BalusC; 15.05.2011