Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


"head" renders valid JSON if response type is "application/json" #8124

wants to merge 1 commit into from

4 participants

Andrew DiMichele Guillermo Iguaran Steve Klabnik Alexandru Ungur
Andrew DiMichele

I was getting javascript exceptions from jQuery using $.post(...) to an action that rendered using head :ok because head returns a blank response body (which is not valid JSON) even though $.post requested "application/json" and the response type was "application/json".

I went ahead and modified "head" put valid JSON in the response body if the response format is "application/json".

This may turn into a philosophical argument, but I would say that if the response claims that its content type is "application/json" that its body be valid for that type.

Guillermo Iguaran

I think this has been discussed in the past but I can't remember conclusions

/cc @spastorino @josevalim

Steve Klabnik

head :ok is shortcut for a 200 with no body. You want render :text => "{}", :status => 200.

I'm :-1: on this.

This may turn into a philosophical argument, but I would say that if the response claims that its content type is "application/json" that its body be valid for that type.

This is true, but just because the client asks for application/json doesn't mean it has to get application/json. That said, we shouldn't return invalid JSON while serving up something that claims to be.

Andrew DiMichele

Saw it was discussed briefly here: #2315, but it doesn't look like anything was really decided.

@steveklabnik Yeah I was wondering where people would land using render vs head... render :text => "{}", :status => 200 is actually exactly how I fixed it in my code. I just thought it would be nice if head :ok was more magical and that the response body matched the content-type, as you mentioned. I figured a little text in the response body wouldn't hurt anybody.

Steve Klabnik

The more that I think about it, since the Content-Length would be 0, I don't think that it matters that "" is not valid JSON.

Alexandru Ungur

Quoting from:

The HEAD method is identical to GET except that the server MUST NOT
return a message-body in the response.

I don't see anything unclear there, that could lead to a philosophical debate. "MUST NOT" MUST (pun not intended) be interpreted as per: which means:

MUST NOT - This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.

If someone expects a body, they should not use a HTTP verb that prevents returning a body in the first place.

Steve Klabnik

Yep, there we go. Thanks for fixing my laziness.

Andrew DiMichele

Guys, HEAD is an HTTP method... we're talking about he Rails head function that generates the response to what could be any HTTP verb (GET, POST, etc.). We could call that function bananas and it wouldn't change those semantics.

Nevertheless I think you're basically right... head must have been designed to respond to the HEAD verb and any other use is done at your own peril.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
This page is out of date. Refresh to see the latest.
6 actionpack/lib/action_controller/metal/head.rb
@@ -31,7 +31,11 @@ def head(status, options = {})
if include_content?(self.status)
self.content_type = content_type || (Mime[formats.first] if formats)
- self.response_body = " "
+ if self.content_type == "application/json"
+ self.response_body = "{}"
+ else
+ self.response_body = " "
+ end
2  actionpack/test/controller/render_test.rb
@@ -1219,7 +1219,7 @@ def test_head_created
def test_head_created_with_application_json_content_type
post :head_created_with_application_json_content_type
- assert_blank @response.body
+ assert_nothing_raised { JSON.parse(@response.body) }
assert_equal "application/json", @response.content_type
assert_response :created
Something went wrong with that request. Please try again.