Currently, the head method doesn't set a default Content-Type, so unless it's explicitly passed in as an argument to head (i.e., head :ok, :content_type => 'whatever'), the Content-Type will be set to the MIME type associated with the response format.
So, for example, from the default scaffold:
# PUT /posts/1
# PUT /posts/1.xml
def update
...
respond_to do |format|
...
format.html { redirect_to(@post) }
format.xml { head :ok }
...
end
end
... if you successfully PUT to /posts/1.xml, you'll get a 200 response with an empty body (in reality, it's a single space), and a Content-Type of "application/xml".
However, this Content-Type is misleading and incorrect, since no XML document is contained in the response body, given that, according to the spec, a well-formed XML document must contain one or more XML elements.
A blank space contains no XML elements, so therefore, it's malformed XML.
Any client that relies on Content-Type to determine how to handle the response body will be mislead -- in a browser, for example, if this response is returned from an Ajax request, a call to XMLHttpRequest.responseXML will return "<parsererror>".
A blank response body is also not a well-formed XHTML, ATOM, RSS, or PDF document.
The proper default Content-Type setting for a blank response body is "text/plain" -- an empty response body qualifies as plain text, and plain text is recognized by every HTTP client.
Additionally, this lets clients know that they don't need to do any additional parsing or evaluation of the response body.
This patch sets this default for the head method -- it can be overridden, if ever necessary, by passing a an explicit :content_type argument:
head :ok, :content_type => 'text/enriched'
Tests included.
