Question

I’m currently using a custom message encoder that does GZIP compression. I would like to migrate that over to step-by-step a solution where I use IIS7’s builtin (HTTP’s “Accept-Encoding: gzip”) compression:

1. update server to support both legacy and HTTP gzip compression
2. gradually update all clients to use HTTP gzip compression
3. potentially remove legacy support

To keep changes in configuration of the infrastructure minimal, I’d like to

• use the same URL for both legacy and HTTP style compression
• on the server side be able to distinguish legacy and new style by looking at the Accept-Encoding (or any other custom header to be added, if necessary) – legacy clients do not send ‘Accept-Encoding’, but new clients would (have to, anyway)

This is a snippet of the configuration of one of the services I intend to migrate:

<service name="SomeService" behaviorConfiguration="Common">
  <endpoint address="" binding="customBinding" contract="ISomeService" bindingConfiguration="GZipBinding">
    <identity>
      <dns value="localhost"/>

In theory, I’d see 2 ways to get this done:

1. Add another endpoint (with same physical address) to the configuration, the new endpoint would use a different binding
2. Make the distinction inside my custom message encoder

The solution – if it exists – to either of those 2 ways has eluded me so far.

1: I don’t think you can make IIS choose the endpoint based on an http header, IIS will use the soap header (I assume) to make the decision, with the client using ClientViaBehavior: http://msdn.microsoft.com/en-us/library/aa395210.aspx

2: When in MessageEncoder.WriteMessage, I don’t think I have access to the request HTTP headers, but if I had, it would be easy to decide whether or not to gzip.

Any ideas how to solve 1. or 2., or is there a better way to get this done, using a shared URL, and not using ClientViaBehavior? (If not, I guess ClientViaBehavior would be my fallback, that at least seems to be doable)

Answer 1

Although in the end I solved the problem completely differently, using a custom SOAP header and modifying the GzipMessageEncoder to look at that header to decide whether to compress, I found the answer, but it might be a bit cumbersome to implement.

Anyway, what lead me to a possible solution was understanding the difference between logical addresses and physical addresses, as explained at http://msdn.microsoft.com/en-us/library/aa395210.aspx . So when you change the address attribute (btw. you don’t need to use the ‘listenUri’ parameter explained in the aforementioned link), it in your code you will have to set the ‘via’ parameter of the Endpoint object to the physical address, whereas the logical address of the Endpoint objects needs to match what you specified in the ‘address’ attribute of the endpoint tag.