Asp.net WCF Rest服务POST数据的透明GZIP解压缩

这是我们的方案（不可协商）：

• 使用IIS7中托管的WebHttpEndpoint通过HTTP公开WCF REST服务
• 作为JSON传输的所有响应和请求后数据
• 非WCF Web客户端
• 我们已经在IIS7中为JSON响应激活了gzip压缩，效果很好

由于我们使用更大的JSON有效负载进行post请求，我们已经为JSON post数据实现了客户端GZIP压缩，并将“Content Encoding”头设置为“GZIP”。不幸的是，IIS没有现成地处理这个问题。post数据以压缩形式到达WCF反序列化程序，这当然会导致异常

我尝试了各种扩展点来连接到WCF管道，但唯一有希望的解决方案（操作行为）不起作用，因为在没有WCF客户端的情况下，将永远不会调用IOperationBehavior接口的ApplyClientBehavior方法

最后，如果实现了一个HttpModule，它完成了工作，但我对结果并不满意，因为有以下警告：

• 虽然我能够通过将当前HttpRequest的Filter属性设置为GZipInputStream来透明地解压缩请求数据，但这只是解决方案的一半，因为WCF坚持从请求中准确读取HttpRequest.ContentLength字节，而对于压缩请求，这显然要比未压缩的字节少得多有效载荷
• 出于我想象不到的奇怪原因，微软阻止了所有合法的方式来更改请求的内容长度。最后，我不得不修改请求的ContentLength属性的私有支持字段。这不是您希望在生产代码中执行的操作
• Microsoft还使我们无法读取HttpModule中的请求InputStream来计算未压缩的内容长度，这要求我们的web客户端也传递一个包含未压缩内容长度的自定义头

---

总而言之，这感觉像是一个可怕的工作，甚至不能实现干净，所以我想知道，如果有人可以指出替代方案，以实现IIS中的解压缩部分。如果有这样的商业产品，我完全可以推荐它。

我想你应该可以用

---

在AfterReceiveRequest中解压缩

不幸的是，调度消息检查器在管道中执行得太晚。我已经试过了，传递给检查器的消息已经处于错误状态。您是否在服务端的端点中使用GZip编码器，或者至少使用解码GZip但正常编码的版本？您是否找到了解决方案？是否有人找到了解决方案？似乎没有已知的解决方案。