Content type Application/xml

Mar 31, 2010 at 2:25 PM
I am running a small issue on http header content type: Application/xml. 1. For test case 3 (Bad XML i.e. not well formed xml’s): We are not actually validating the XML when we receive it, the error that is being thrown is prior to the meat of our code being executed. Basically you are getting a 400 due to the fact that the data type you are sending to it does not meet the definition. 2. For best practice, what we can do is change the content type to Plain/Text and then validating the XML as far as being valid XML or invalid XML. 3. I am using .net web service and using XElement to accept the pay load. As of my knowledge about ‘Application/xml’ means receiving or sending well formed XML. Is anyone come across this issue? Link about Application/xml: Thanks, Rao
Mar 31, 2010 at 2:49 PM
Here is some background to why a synchronous HTTP 200 is expected with an asynchronous Acknowledgement with error details, and not a synchronous HTTP 400, when the request has bad XML (not well formed XML). During the development of the IAB eBusiness specifications one of the design points is that no content processing should be performed until after the synchronous response is returned. This is because message performance can be a problem when message size and volume increases. Also because the acknowledgement should be used to send back error details, which the HTTP response can't. This design requirement might not have been explicitly captured in the current IAB eBusiness Technical Specifications. If it hasn't, we propose it is added. Regards, Sandy
Mar 31, 2010 at 6:57 PM

Here is more about the issue. When we say content-type: application/xml it means that we are receiving/sending xml (means well formed) in the payload. Passing bad xml means passing a text or string to the method instead of xml.

 For example, if you were needed to create a method that accepted integer, sending a string would throw an error before the contents of the method was executed.  So in the case of passing malformed XML into a strongly typed XML parameter, we are throwing the error prior to any content being received. 

 As we suggested in the past, in order to accommodate receiving malformed XML we would need to accept Plain/Text so that we could store that in our datastore and validate the payload at a later time.

 To summarize, we do not validate the contents of the payload, just the fact that the payload is the correct datatype, if a payload came across as just <payload></payload>, we would receive it, respond with a 200 and then validate it at a later date.