XmlProcessor and not serializable object instances

Topics: Web Api
Feb 15, 2011 at 5:15 PM


1) I've a service with several media type processors registered for the response (XmlProcessor, JsonProcessor, custom Atom processor)

2) On a request with "Accept: application/xml, ...", the XmlProcessor is selected to encode the response. However, the object instance (an iterator object) is not serializable, so an exception is throwed. Unexpectedly, the response is a "200 OK" with content-lenght = 0 and not a 500. 


1) Why is the exception on the XmlProcessor being ignored?

2) What should be the desired behavior?

i) "500", because an exception was throwed inside a pipeline?

        ii) "406", because the selected media type processor (the XmlProcessor) was unable to process the representation?

        iii) Try another media type processor that handles an accepted media-type.

IMHO, the desired behavior should be iii)

One could ask why is the XmlProcessor registered, when the returned object instance is not XML serializable. It is true that one can use the HttpOperationDescription registration parameter to check if the XML serialization makes sense, however, this decision process is not easily feasible (for instance, the operation return type may be void)


Pedro Félix

Feb 15, 2011 at 6:00 PM

Hi Pedro,

I don't know why the exception is being ignored, but I would go with a default of 500 for any unhandled stuff in the server.

As for the desired behavior, I think that 406 is more semantically correct if you want to comunicate to the client that the specific resource does not have the requested representation(s) (from the accept header). This could be the case of a resource with representations in jpg/png format, and only taking these formats in the accept headers. Nevertheless, I would try to avoid adding the processor to those special resources. That's how it's being currently handled by the stack. If you don't want to do that, you can ask for the HttpResponseMessage (as an in argument) in a custom processor, and set the status code there, and even provide some useful information like what are the accepted formats for that resource.

As for option (iii) I guess it's reasonable to think that if the server didn't handle a media type very well, that it could try with a different one from the accept headers, but that sounds like something we should be able to choose from.


Gustavo Machado