tags:

views:

7

answers:

1

Let say I have a WCF

Foo(int param);

The client is passing in a JSON string. Instead of passing in an integer, they pass in a string.

The system now returns a 500 error back to the client. The event log says that I need to add includeExceptionDetailInFaults="true" to my config file if I want a friendly message to be returned. I go and do that but then I still get the 500 error and an event log error stating that I cannot add the 'serviceDebug' extension to my endpoint behavior because the underlying behavior type does not implement the IEndpointBehavior.

What does that suppose to mean?

A: 

First of all: where did you add the <serviceDebug> behavior, and how? Can you show us? The <serviceDebug> needs to be added to the <serviceBehavior> section on your server - not the endpoint behavior section. It's a service behavior, after all (it affects the whole service) - not an endpoint behavior (which affects only a single endpoint but not others).

So you should have:

  <serviceBehaviors>
    <behavior name="debug">
      <serviceDebug includeExceptionDetailInFaults="true"/>
    </behavior>

in your server-side config (web.config or app.config), and then apply that service behavior to your service tag:

<services>
   <service name="...."
            behaviorConfiguration="debug">
    ....

Secondly: error 500 is an internal server error, so this means, the server couldn't interpret and handle your input. The best bet would be to do some client-side validation before actually sending this input to the service, to avoid these kind of errors.

If you cannot do this, then maybe you need to add some more logic to your service so you can capture and figure out these kind of errors before they blow up your service code.

And thirdly, the ultimate solution: you could write a client-side parameter inspector to catch these wrong parameters even before they're being sent to the server, and react accordingly. WCF is very extensible that way. See the MSDN How To Inspect Or Modify Parameters or this blog post if you're interested in learning more about parameter inspectors.

marc_s
I agree that client code should be doing validation. However, the server returning a 500 error makes it very hard to identify the root cause with client code that don't validate properly. Also, the point of "blow-up" was prior to the service code actually executing due to the fact that the framework couldn't convert a character into an int. Anyway, your point about serviceBehaviors vs. endpointBehavior was correct. I made the change and the problem went away.
@mrbd: well, the design of WCF is to be secure by default. This also means not revealing anything about the service to (potentially malicious) callers, either. Detailed error messages are great for developers - and for thugs wanting to attack your system. WCF deliberately send back generic "error happened" messages for that reason.
marc_s