在项目中，我们需要修改由ASP.NET页/ web服务/根本不产生什么的响应。如果您搜索实现此目的的最佳方法，那就是创建一个HttpModule，然后在其中添加自己的流到Response.Filter。它为您提供了传入流，并且您编写了自己的修改后的流。一切都很好。此建议的一个示例是here。
如果您主要提供文本内容，则使用服务器和浏览器多年以来的压缩功能非常有用且很重要。就IIS和我提到的页面/ Web服务的类型而言，应该是Dynamic Compression。真好它本身也起作用。它也可以处理来自（1）的那些额外处理的请求。
这很有趣：来自（1）的过滤器流现在不再接收文本内容，而是接收应该转换的传入流中的压缩字节。哎呀事情的顺序肯定是错误的。文本内容应先处理，然后压缩。
我的第一个猜测是，我应该在DynamicCompressionModule之前获得自定义HttpModule火。实际上，每个应用程序都有一个模块排序，尽管我必须首先从服务器级别的本机模块中删除锁。它没有帮助。花了一些时间研究和查看FREB s。
找出重要的是管道。 Described here。动态压缩模块在RELEASE_REQUEST_STATE上执行其工作。自定义模块也是如此。但这没关系。自定义模块在运行该事件时实际上并未执行转换。设置Response.Filter。过滤器何时启动？一些更多的挖掘和调试工作，是在AspNetFilterModule运行期间触发的。
虽然您不会在IIS设置中看到AspNetFilterModule。您会在哪里看到the source code of HttpApplication。它是ASP.NET本身添加的伪模块，用于运行筛选器链。它已订阅... UPDATE_REQUEST_CACHE通知。 after进入RELEASE_REQUEST_STATE。无论您如何订购模块，都将在压缩后进行。
因此，不可能使用Response.Filter进行文本后处理并同时使用标准DynamicCompressionModule。这是我寻求帮助的地方。没有人有这种情况吗？感觉很普通。
是否有一种方法可以使用Response.Filter在无的情况下转换HttpModule中的文本输出？最好是在RELEASE_REQUEST_STATE事件上执行模块时。 Response.OutputStream可用，但是它是只写的，没有明显的方法可以读取我看到的当前输出流。