2012-02-02 189 views
6

这是我们的场景中(这是没有商量余地):透明GZIP压缩

  • WCF REST服务公开了使用IIS7托管WebHttpEndpoint HTTP
  • 所有响应和POST请求数据以JSON形式传输
  • 非WCF Web客户端
  • 我们已经在IIS7中为JSON响应激活了gzip压缩,并且工作正常。

由于我们正在做更大的JSON负载的发布请求,我们已经为JSON发布数据实现了客户端GZIP压缩,并将“Content-Encoding”头设置为“gzip”。不幸的是IIS不能处理这个问题。发布数据以压缩形式到达WCF解串器,这当然会导致异常。

我试过各种扩展点挂钩到WCF管道,但唯一有希望的解决方案(操作行为)没有工作,因为没有WCF客户端,IOperationBehavior接口的ApplyClientBehavior方法将永远不会被调用。

在如果实施的HttpModule它能够完成任务,但我不是,因为以下注意事项的结果正是幸福的结尾:

  • 虽然我能够通过设置透明地解压缩请求数据当前HttpRequest的Filter属性为GZipInputStream,这只是解决方案的一半,因为WCF坚持从请求中准确读取HttpRequest.ContentLength字节,对于压缩请求将明显比未压缩的有效负载小得多
  • 出于某种奇怪的原因我的想象力微软已经阻止了每一种合法的方式来改变r的ContentLength eQUEST的。最后,我不得不修改请求的ContentLength属性的专用支持字段。这不是你想要在生产代码中做的事情。
  • 微软也使人们无法读取HTTP模块请求的InputStream弄清楚这需要我们的网络客户端还传递包含未压缩的内容长度

这所有的一切感觉就像一个自定义标题中的未压缩的内容长度很多工作甚至无法完全实现,所以我想知道是否有人可以指出在IIS中实现解压缩部分的替代方案。如果有商业产品的话,我完全可以推荐它。

+0

你找到了一个解决方案? – Snowy 2012-05-22 03:46:45

+0

有没有人找到解决方案? – 2013-01-10 16:35:39

+0

似乎没有一个已知的解决方案。 – 2013-01-15 15:02:30

回答

0

我想你应该能够与service side Message inspector

解压为此在AfterReceiveRequest

+0

不幸的是,调度消息检查器在管道中执行得太晚。我已经尝试过了,传递给检查员的消息已经处于错误状态。 – 2012-02-02 09:59:37

+0

您是否在服务端使用端点上的GZip编码器进行了研究http://msdn.microsoft.com/zh-cn/library/cc138373(v=VS.90).aspx或者至少有一个解码GZip但通常编码 – 2012-02-02 10:52:33