В настоящее время я работаю над веб-сайтом, доступ к которому осуществляется через https. Недавно мы столкнулись с проблемой, при которой мы не можем просмотреть .pdf файлы или любой другой тип файла, который отправляется как вложение (Content-Disposition:attachment).
В соответствии с База знаний Microsoft это связано с тем, что Cache-Control установлен на no-cache. Однако у нас есть требование, чтобы все страницы полностью перезагружались при каждом посещении, поэтому мы отключили кеширование на всех страницах (через наш код ASP, а не через настройки IIS).
Однако я сделал особый случай этой страницы, которая показывает вложение, и теперь она возвращает заголовок с Cache-Control:private и срок действия установлен на 1 минуту в будущем. Это отлично работает, когда я тестирую его на своем локальном компьютере, используя https. Однако, когда я развертываю его на нашем тестовом сервере и пробую, заголовки ответа все равно возвращаются Cache-Control:no-cache.
Между мной и сервером нет брандмауэра или чего-либо еще, поэтому сам IIS должен добавлять эти заголовки и заменять мои. Я понятия не имею, зачем он это делал, и на самом деле это не имеет никакого смысла, но, похоже, на данный момент это единственный вариант (я еще не нашел другого места в коде, которое изменило бы заголовки кеша ).
Может ли кто-нибудь указать мне возможное место, где IIS может устанавливать эти значения заголовка?
РЕДАКТИРОВАТЬ: Оказывается, IIS не было возиться с настройками моего кеша. Скорее, папка, в которой я публиковал, не была той же папкой, из которой служил IIS. Я обнаружил это, когда изучил пути и заметил, что файлы, которые обслуживает IIS, были слишком старыми. Указание IIS на правильную папку устранило все мои проблемы.
Есть несколько мест, которые могут контролировать кеширование в IIS.
Все настройки должны быть сохранены в web.config если соответствующая конфигурация функции может быть сохранена локально (см. Делегирование функций), в противном случае она сохраняется в основном файле конфигурации: RootWeb.config (часть .NET framework, например: C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG\web.config) и / или ApplicationHost.config (C:\Windows\System32\inetsrv\config\ApplicationHost.config). Запуск Консоль управления IIS (Диспетчер IIS), затем «Редактор конфигурации», затем «Конфигурация поиска» (на боковой панели), и вы сможете увидеть ВСЕ файлы конфигурации, известные IIS, а также выполнить поиск определенных параметров.
Заголовки ответа HTTP - скорее всего, место, о котором нужно позаботиться: может быть пользовательская настройка заголовка, которая явно запрещает кеширование .. или через «Установить общие заголовки ...» на боковой панели / меню содержимого.
Кэширование вывода может также повлиять на заголовки кеширования (я никогда не использовал его сам и не могу сказать больше).
Перезапись URL v2.x также можно использовать для перезаписи заголовков ответов (исходящие правила).
P.S. Этот вопрос будет уместнее задать на ServerFault - это скорее вопрос категории "сисадмин", чем веб-мастеров.
Как я решил свою проблему (поскольку я также отредактировал вопрос, но добавил сюда, чтобы отметить это как решенное).
Оказывается, IIS не возился с настройками моего кеша. Скорее, папка, в которой я публиковал, не была той же папкой, из которой служил IIS. Я обнаружил это, когда исследовал пути и когда заметил, что файлы, которые обслуживает IIS, были слишком старыми. Указание IIS на правильную папку устранило все мои проблемы.
В моем случае оказалось, что «Расширения» в настройке вывода кэширования были «.ext», а не просто «ext», поэтому установленная мною политика не вступила в силу. После этого я также обнаружил, что мне не нужно устанавливать заголовок ответа Cache-Control.