The default RESTful scaffold update and destroy methods, when called via the .xml api, return HTTP 200 OK responses with blank response body, and the Content-Type header set to "application/xml".
This Content-Type header is technically incorrect -- the response does not contain a valid XML document (given that, according to the spec, a well-formed XML document must contain one or more XML elements.)
Real-world problems occur when the client tries to parse/evaluate the response body based upon the Content-Type -- for example, when this response is delivered to a browser's XMLHttpRequest object as the result of an Ajax call, the responseXML will be "<parsererror>". If the client has implemented error handling logic that sniffs for parsererrors, this logic will be triggered, and thus a Rails success message will be handled as an error by the client.
I've created a patch that sets the default :content_type for the head method to "text/plain" -- this is a sensible default for a blank response body, given that, 1. it's appropriate for the contents (i.e, not misleading or incorrect), and 2. all HTTP clients recognize it.
This default can be overridden, if necessary, but I can't think of a use case where you'd need to label a blank response body as anything other than text/plain.
Patch is here: http://dev.rubyonrails.org/ticket/9524
