1

我正在尝试对我的 WCF 消息的内容进行 gzip 编码。我看到的大多数示例都在谈论拥有 BindingElement 和 MessageEncodingFactory。

在 IDispatchMessageInspector 的 BeforeSendReply 中执行此操作是否有任何副作用？即，我接受消息，将其压缩并替换原始消息。

public void BeforeSendReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
{
     HttpResponseMessageProperty httpResponseProperty = new HttpResponseMessageProperty();
     httpResponseProperty.Headers.Add(HttpResponseHeader.ContentEncoding, "gzip");
     reply.Properties[HttpResponseMessageProperty.Name] = httpResponseProperty;
     reply = gzip(reply);    
}

gzip 是提取（xml）主体并将其替换为压缩字节流的功能。

我正在寻找类似的东西

  • 不！那会杀死你的服务器。
  • 不，这会破坏比 x 更长的消息。
  • 这不是一个好主意，因为客户端会将其视为带有随机字节序列的消息，而不是 gzip 压缩消息。
  • 是的，这行得通。而且对性能的影响不会那么大。

谢谢各位！

4

1 回答 1

2

这可能会或可能不会起作用，具体取决于您使用的绑定。如果您使用任何基于 SOAP 的绑定（BasicHttpBinding、WSHttpBinding、NetTcpBinding 等），这将不起作用，因为它使用的编码器不知道如何将消息的 gzip 压缩版本写入线路（它使用毕竟是 XML 编写器）。

如果您使用非 SOAP 绑定（例如 WebHttpBinding），那么它可能会起作用（您应该尝试确认）。如果您正在处理非常大的消息，您将受到多次缓冲的惩罚（在 GZip 之前和 GZip 之后）。您需要记住将 设置WebBodyFormatMessageProperty为Raw以确保编码器不会尝试重新编码消息（有关此内容的更多信息，请参阅这篇文章）并适当地格式化消息。

此外，您需要确保客户理解它。特别是关于您的第三点 - 客户端始终将消息视为一系列字节，并且由它来“理解”它（例如，通过将其视为 HTTP 响应，将其标头和正文分开，等等上）。

于 2013-10-08T23:21:46.707 回答