В проекте нам нужно было изменить ответ, который генерируется страницами ASP.NET / веб-службами / не имеет значения, что.Если вы ищете лучший подход для этого, это создать HttpModule и добавить собственный поток в Response.Filter.Это дает вам входящий поток, и вы пишете свой собственный измененный поток.Все хорошо и мило.Примером этого совета является здесь .
Если вы работаете в основном с текстовым контентом, очень полезно и важно использовать возможности сжатия, которые были доступны для серверов и браузеров.года.С точки зрения IIS и типа страниц / веб-сервисов, которые я упомянул, это будет Динамическое сжатие .Ницца.Это работает само по себе.Работает и с этими дополнительно обработанными запросами из (1).
Хотя это забавно: вместо текстового содержимого поток фильтра из (1) теперь получает сжатые байты во входящихпоток, который он должен преобразовать.Упс.Порядок вещей определенно неправильный.Сначала нужно обработать текстовые сообщения, а затем распаковать их.
Мое первое предположение: я должен получить специальный огонь HttpModule перед DynamicCompressionModule.Действительно, существует порядок модулей для каждого приложения, хотя сначала мне пришлось снять блокировки с собственных модулей на уровне сервера.Это не помогло.Несколько раз изучал и смотрел на FREB s.
Оказалось, что важен конвейер. Описано здесь .Модуль динамического сжатия выполняет свою работу в RELEASE_REQUEST_STATE.Так же как и пользовательский модуль.Но это не важно.Пользовательский модуль на самом деле не выполняет преобразование, когда он запускает это событие.Устанавливает Response.Filter.Когда срабатывает фильтр?Еще некоторые копания и отладки, они запускаются во время запуска AspNetFilterModule.
Вы не увидите AspNetFilterModule в настройках IIS.Там вы увидите исходный код HttpApplication .Это псевдомодуль, который добавляется самим ASP.NET для запуска цепочки фильтров.И он подписан на ... UPDATE_REQUEST_CACHE уведомление.Это идет после RELEASE_REQUEST_STATE.Независимо от того, как вы упорядочите модули, это будет после сжатия.
Таким образом, невозможно выполнить постобработку текста с Response.Filter И одновременно использовать стандартный DynamicCompressionModule.Вот где я ищу помощи.Ни у кого не было такого сценария?Это обычное явление.
Есть ли способ преобразовать вывод текста в HttpModule без с помощью Response.Filter?Предпочтительно прямо, когда модуль выполняется по событию RELEASE_REQUEST_STATE.Response.OutputStream доступен, но он доступен только для записи, и нет очевидного способа прочитать текущий поток вывода, который я вижу.