Странность с пристанью, обслуживающей изображения

Question

Я полностью в тупике. Я приведу фон для полноты картины, но я не уверен, поможет ли это или нет. Я запускаю проект Lift на стандартной установке Jetty с одним экземпляром Lift. Mac OS X.

У меня есть фрагмент, который преобразует входные данные XML, отображает изображение, сохраняет его на диск в каталоге webroot / images / с именем файла, взятым из MD5 содержимого, например, "c5669d3eedcf7d305dcf9f88a61b3ee0. PNG». Затем фрагмент возвращает тег img со ссылкой на сгенерированное изображение для включения в вывод.

Большую часть времени большинство изображений работают. Но в большинстве случаев некоторые из них этого не делают, а некоторые изображения не отображаются браузером. Попытка просмотреть проблемное изображение в браузере (Camino и Firefox) не работает: изображение не отображается, что говорит о том, что что-то не так.

Просмотр его в другом браузере (Safari и с QuickTime),изображение работает отлично. Загрузка и открытие изображения работает нормально. При просмотре файла напрямую с Camino (то есть file: // ...) изображение выглядит нормально: сам файл явно не поврежден.

Это не может быть длина имени файла, потому что все имена файлов имеют одинаковые 37 символов.

Я могу только предположить, что что-то идет не так при транспортировке изображения при подаче через Jetty.

URI, которые терпят неудачу, терпят неудачу последовательно, это не прерывисто. Перезапуск Jetty не имеет значения, поэтому я не думаю, что файл был создан после запуска сервера. Кроме того, рендеринг является блокирующим вызовом, поэтому нет никаких шансов, что файл все еще открыт / не был сохранен до отправки HTML-кода и браузер запрашивает изображения.

Единственное, что я могу себе представить, эточто MIME-тип искажен, поэтому я поместил соответствующее отображение в web.xml, но сигары по-прежнему нет. Тип MIME выглядит нормально, и я проверил, что число байтов правильное.

Для изображения проблемы:

HTTP/1.1 200 OK
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID=1dbeh8eq4mtu0;Path=/
Content-Type: image/png
Content-Length: 25488
Last-Modified: Sat, 25 Jul 2009 15:38:19 GMT
Server: Jetty(6.1.16)

Для полноты, заголовки из изображения, которое делаетнагрузка в порядке:

HTTP/1.1 200 OK
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID=15dt649lzovc4;Path=/
Content-Type: image/png
Content-Length: 18657
Last-Modified: Sat, 25 Jul 2009 15:41:35 GMT
Server: Jetty(6.1.16)

Очень, очень озадачен по этому поводу. Какие-нибудь подсказки?

Приветствия

Джо

Answer 1

У меня похожая проблема. Мне кажется, что Jetty обрабатывает изображение как текст и пытается закодировать его в UTF-8. Я сделал тестовые данные, которые содержат только 7-битные данные, и они работают просто отлично, но когда данные содержат байт, в котором установлен 8-й бит, они преобразуются в несколько байтов, как в кодировке UTF-8.

Поскольку файлы PNG всегда начинаются с байтов 0x89, 0x50, 0x4e, 0x47, при обслуживании с нарушенной настройкой Jetty первые 0x89 преобразуются в 0xef, 0xbf, 0xbd. Это код UTF-8 0xfffd, который AFAIK означает «неправильный символ UTF», или что-то в этом роде.

Я думаю, что это должно быть что-то в среде, так как такая же настройка работает на моих собственных компьютерах Mac и Linux,но постоянно терпит неудачу на другом компьютере с Linux и на одной машине с Windows.

Answer 2

Я не уверен, проверяете ли вы URL-адреса позже из curl / wget или используете анализатор пакетов для получения заголовков, но на всякий случай это первый. Я бы попробовал использовать инструмент, такой как HTTPScoop , чтобы убедиться, что фактические данные, отправляемые в Firefox, соответствуют ожидаемым данным.

Единственное, что меня поражает, - это разница в размере. Это вообще большие изображения, которые терпят неудачу? Если так, я бы сказал, что это какая-то неработающая буферизация / очистка файла.

Answer 3

Вы служите из банка? У меня та же проблема, но ТОЛЬКО с PNG со слоями прозрачности, и ТОЛЬКО при обслуживании вне JAR. Если я прокручиваю его, он сразу же выскакивает до 100%, но продолжает «загружать», пока не достигнет тайм-аута 30 с.