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.
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
body:
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.