Случай Загадочного Контента-Заголовка - PullRequest
Новая
       6

Случай Загадочного Контента-Заголовка

1 голос
/ 02 июля 2011

Наш продукт включает в себя приложение Flash, загружаемое SWFObject.Для одного клиента при доступе к этому SWF-файлу через HTTPS (но не через HTTP) Flash Player не будет загружать его.

Я попросил клиента перейти непосредственно к URL-адресу SWF-файла (а не к странице обертки):

  • Когда он делает это через HTTP, SWF-файл загружается в браузер.
  • Когда он делает это через HTTPS, IE7 представляет ему диалоговое окно «Сохранить файл».Это означает, что в ответе присутствует заголовок «Content-Disposition: attachment».Это также объясняет, почему SWF-файл не загружается во Flash Player: в качестве меры безопасности он не будет воспроизводить SWF-файлы, обслуживаемые этим заголовком.

Итак, у меня есть пара вещейпытаясь выяснить:

  1. Как я могу быть уверен, что заголовок Content-Disposition отправляется сервером (а не является странным артефактом IE7)?Пользователь имеет в своем распоряжении только IE7 и не может использовать Firefox, Chrome и т. Д. В IE7 нет удобной вкладки «Сеть», которая присутствует в инструментах разработчика IE9.

  2. Предполагая, чтозаголовок присутствует, как там дела?Они работают с Tomcat 6. SWF обслуживается сервлетом Tomcat по умолчанию.Заголовок представляется присутствующим, если используется соединитель HTTPS, но не, если используется соединитель HTTP.Конфигурация Tomcat является стандартной, за исключением включения коннектора HTTPS.

Кстати, я не доверяю очистке кэша Flash.На моей машине под IE9 SWF часто удовлетворяется кешем даже после того, как я явно очистил кеш браузера и сохраненные данные Flash Player: я не вижу ни одного запроса в Fiddler или в журналах доступа Tomcat, но SWF загружается вбраузер.Я что-то здесь упускаю?Может ли клиент получить доступ к какой-то фиктивной кэшированной версии SWF?

Редактировать: Очевидно, что команда очистки кэша в инструментах разработчика не действительно очистить кеш.Использование стандартного метода дало ожидаемые результаты.

Редактировать 2: Трассировка в Tomcat указывает, что заголовок Content-Disposition не установлен.Я не знаю наверняка, что это не получено браузером, но AFAIK браузер соединяется непосредственно с Tomcat.Это кажется странным поведением на стороне браузера.

Ответы [ 2 ]

2 голосов
/ 07 июля 2011

Проблема была связана с наличием следующих заголовков в ответе: 

Cache-Control: no-cache
Pragma: no-cache

Они были отправлены Tomcat, поскольку страница была защищена ограничением безопасности (настроено в conf / web.XML).Эти заголовки заставили IE7 работать так же, как присутствовал заголовок 'Content-Disposition: attachment'.

Мое решение состояло в том, чтобы клиент добавил следующую конфигурацию в файл Tomcat conf / context.xml: 

<Valve className="org.apache.catalina.authenticator.BasicAuthenticator" securePagesWithPragma="false" />

Это заменяет заголовки на: 

Cache-Control: private

..., которые все еще должны выполнять задачу предотвращения кэширования страницы прокси при работе с проблемами IE.Это было основано на решении, найденном здесь:

http://daveharris.wordpress.com/2007/07/09/how-to-configure-cache-control-in-tomcat/

Однако это очень похожее решение полностью подавляло заголовки.Подробную информацию об этих атрибутах можно найти в документации Tomcat здесь:

http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Basic_Authenticator_Valve/Attributes

1 голос
/ 02 июля 2011

Вы должны иметь возможность регистрировать исходящие ответы HTTP на стороне сервера перед шифрованием, использовать нулевой шифр или предоставлять ключи RSA для wireshark и просматривать заголовки из захвата пакета.

...