Compression

Question

What is the best way of implementing compression for a secured WCF service?

 

Answer 1

Hi Catalin,

 

There are basically three ways to implement compression in WCF.

 

1. At transport level using a message encoder which compress all the data throughout the entire channel (From the client to the service). There is a sample of this in the WCF SDK,  [SDK Folder]TechnologySamples/Extensibility/MessageEncoder/Compression

 

2. At message level, adding some metadata to the soap message (Soap headers) and compressing the soap body. This approach can use a WCF binding or a MessageInspector Behavior to modify the soap messages. You can find an example here, http://weblogs.asp.net/cibrax/archive/2006/03/29/WS_2D00_Compression-for-WCF.aspx

 

3. Only for the Http transport, you can use the Http Compression capability. I haven't seen any implementation of this technique so far.

 

I hope this can help you

Regards,

Pablo.

 

Answer 2

i've allready tried the encoding approach.

with an compression encoder i have to use transport security (only https).. message security would be applied before the encoding process.

compressing a encrypted mesage inflates it a lot.

 

using transport security with message credentials is ok, but i would like to have the tcp transport available, if possible.

 

 

i'll try the mesage inspector approach.

 

thx.

Answer 3

There is one transport level implementation that is commercially available that does HTTP style compression/decompression, i believe i read somewhere that it supports compression using http sytle using Accept-Encoding and Content-Encoding, it is called LiteHttpTransport and is available from a company www.noemax.com .

I personally see it as a huge pain to reinvent the wheel to write the entire transport for http for acheiving something as simple as reading/writing from the httprequest(response)context. It would have been a lot easier if the WCF team would have provided some mechanism to plugin some code to handle the r equest/response context on the service side.
Using reflector it seems like everything in the WCF httptransport code is hardcoded to use specific classes without any possibility of attaching even an extension of a class. Let me know if i have missed something on this front.

The workable alternatives that are close to http style comp/decomp at this time are
a) Run the service on a local loopback interface/named pipes and then run a embedded httpserver to do the compression/decompression while proxying the requests/responses to the local interface.
b) write a the http transport all from scratch.
c) or use a commerically available transport that supports http style compression driven by use of http headers.

Of the above, i am personally inclined towards (a) above but i have yet to measure the performance hit that the service would suffer given that i already have the compression/decompression working as a message encoder (as per Microsoft's example with some improvements added).

Answer 4

http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/ca7287b4-f553-4c8f-bc0f-1ef68a5e420e/