This is a major issue for me. In earlier times, web service clients could simply use EnableDecompression = true and all was good, but why did Microsoft not add something similar to WCF?
I really NEED gzip compressed responses from my WCF services (and they need to be http... legacy issues, as usual... you know...).
Check out this blog post which basically ends up suggesting:
Conclusion
I now ditched this as we also need to support clients that do not set the AcceptEncoding header so I really need the ability to read the http header in request and set a "context" value to (not) compress the response and I have not found out yet how to do that per multiple concurrent requests. I really recommend to use the IIS http compression and not try to do this with WCF hacking as described here!
There's also a WCF Extensions project on Codeplex which has a WCF Compression Channel - maybe that'll be what you're looking for.
The most bang for the buck would be to use the binaryMessageEncoding in WCF instead of the textMessageEncoding (which is the default for HTTP bindings). That would require you to create a custom http based binding, and would render your service incompatible with other http-based clients other than .NET clients that are also using the same custom binding configuration.