Choosing the right HTTP response code for incorrect POST data

Question

I suspect this is a very trivial question. I'm writing a PHP script to respond to an AJAX query. The query should include some XML data, which the PHP script processes and then returns a response to. There are two error cases I want to consider:

1. No POST data in the request; or
2. Bad data in the XML (either not valid or well-formed XML, or fails some schema checks)

In such cases I believe I should be returning a 4xx response code. Is there anything more appropriate than 400?

More Details

To illustrate the problem further: The client Javascript application is a diagram editor for educational purposes. The user is required to create a diagram that correctly models a given situation. The student can then submit the diagram, whereby an XML serialization of the diagram is POSTed via an AJAX call to the server. A PHP script analyses the diagram XML and constructs an XML report that is sent as the AJAX response to the client. The two situations I originally described (no XML POST data or invalid XML therein) should not happen when requested by the client, but I think it prudent to correctly capture and deal with these situations. Hence my belief that a 4xx response code is appropriate. The XML report structure doesn't cater for these situations, and an empty report would amount to a perfect diagram, which clearly is not appropriate,

Answer 1

Based upon the meanings of the codes in the TCP/IP Guide it seems like 400 is your best choice. Nothing there seems to meet your example.

Answer 2

I think the two error cases you mentioned actually would be served with different HTTP status codes. From the W3C's Status Code Definitions:

400 Bad Request - The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

409 Conflict - The request could not be completed due to a conflict with the current state of the resource.... For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request....

So the 400 is for cases when the request body can't even be parsed due to syntax problems. The 409, in contrast, seems to be for cases when the request body is parsed and the server understands the request all right, but is refusing to fulfill it because of business rules.

In the case of failing schema validation or bad XML syntax, I agree with the other posters, 400 is appropriate. But in the case of no POST data, which you say is a valid diagram but not acceptable for other reasons, 409 seems more appropriate to me.