Address Filters that Swallow GET

Many services consist of more than one message processing strategy. Typically, you think of services as being represented by their application endpoints. When the service receives a message, the decision to route the message to one of those endpoints is done by applying message filters until a winning endpoint is determined. However, services also possess infrastructure endpoints to handle tasks like metadata retrieval. These endpoints are also potential routing targets so the decision from filtering has to span both collections of endpoints.

One consequence of having both infrastructure and application endpoints is that it's entirely possible for the defined filter set to be internally consistent for each of the collections but have conflicts when considering the combined set of endpoints. Whenever there is a conflict, some resolution process must take place and pick one of the endpoints to receive the message. Since you primarily think of your application endpoints, you may not consider that you've created a conflict with one of the infrastructure endpoints. Your application endpoints might not win that conflict. The most common symptom of a conflict is that you'll get an exception because the wrong endpoint is trying to process your message. For example, you'll see an address filter mismatch exception that looks like this:

The message with To '...' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree.

A sometimes surprising source of this conflict is seen when you switch an operation from using the normal POST to use GET. The service help page and metadata endpoint tend to win conflicts directed to their location or any subpath of their location that use a GET request. You can disable or move these infrastructure endpoints to resolve the conflict through the ServiceDebugBehavior or ServiceMetadataBehavior, respectively, in the configuration or through code. Alternatively, you can move your application endpoint to resolve the conflict that way.

Next time: Turning Off Principal Handling

Comments

• Anonymous
  September 13, 2007
  The comment has been removed