Запрет Tomcat от добавления кодировки к бинарным типам контента

Question

У нас есть служба на основе 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 добавлять кодировку к типу контента для двоичных данных?

Answer 1

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

response.setCharacterEncoding("UTF-8");

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

Answer 2

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

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

Answer 3

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

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