Missing Content-Length header breaks ActiveResource 3.1 on create


I've recently moved a 3.0 app ta 3.1 and am finding that
ActiveResource breaks after a successful post because we now check for
the presence of the Content-Length header[1] after a successful create
(basically whenever the API returns a 201). The API is also on 3.1,
and this only happens on staging/pre-prod/prod.

I'm still investigating, but one thing that is clear is that the API
response doesn't have a Content-Length header and this causes
AResource to break; the fact that this only happens on the prod server
seems to point at the fault probably lying with Apache.

Has anyone run into a similar issue?

Sidu Ponnappa.

[1] http://is.gd/c5wsjk

Has anyone run into a similar issue?

Hi Sidu,
I ran into this as well and submitted a pull request:


The patch brings ActiveResource in line with HTTP 1.1 when determining
whether to read the body of a response. The dependency on
Content-Length was originally introduced in the following commit to
combat parse errors when a 204 response (correctly) doesn't include a


Elsewhere, Rails stopped sending a Content-Length header when
bootstrapped from config.ru (though it uses the ContentLength
middleware from `rails server` which is why you probably saw it
working in dev). This is acceptable behavior for a Rack app:


Some rack servers, like Thin, add the header on their own, so as a
happy accident, everything works fine on many production setups even
without #2678 applied.

While I'm here I'll also shamelessly plug my other pending ActiveResource patch:


With both applied to my fork of Rails, I've been happy with
ActiveResource in 3.1.


Sounds like this is probably due to Rails returning a 304 not
modified, which doesn't have a Content-Length header. ActiveResource
should be able to handle that, or it shouldn't send an
if-modified-since header if it can't deal with the 304.


Hi John,

Awesome, thank you. I was planning to do this over the weekend, but you’ve saved me the effort.