Implementing gzip in BeforeSendReply (IDispatchMessageInspector) - wcf

Question

I am trying to gzip encode the contents of my WCF message. Most of the examples I see talk about having an BindingElement and MessageEncodingFactory.
Are there any side effects to doing this in the BeforeSendReply of IDispatchMessageInspector? i.e. I take the message, zip it up and replace the original message.
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 being the function to extract the (xml) body out and replace it with a gzipped byte stream.
I'm looking for something along the lines of
Nooo!! That would kill your server.
Nope, that would break messages longer than x.
Not a good idea because the client would see this as a message with a random series of bytes as body, not as a gzipped message.
Yep, this works. And the impact on performance wouldn't be that huge.
Thanks folks!

Answer 1

This may or may not work, depending on which binding you're using. If you're using any SOAP-based bindings (BasicHttpBinding, WSHttpBinding, NetTcpBinding and so on) this would not work, since the encoder used by it wouldn't know how to write the gzipped version of the message to the wire (it uses a XML writer after all).
If you use a non-SOAP binding (such as WebHttpBinding), then it might work (you should try it to confirm). If you're dealing with very large messages you will incur the penalty of buffering it all a couple of times (before GZip and after GZip). You'll need to remember to set the WebBodyFormatMessageProperty to Raw to make sure that the encoder doesn't try to reencode the message (see this post for more information on this) and format the message appropriately.
Also, you need to make sure that the client understands it. With respect specifically to your third point - the client always sees the message as a series of bytes, and it's up to it to "understand" it (for example, by treating it as a HTTP response, separating its header and body, and so on).