Rails core - Sep 2011 - Missing Content-Length header breaks ActiveResource 3.1 on create

Hi,

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?

Thanks,
Sidu Ponnappa.
http://c42.in
http://blog.sidu.in

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

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

>
> Has anyone run into a similar issue?
Hi Sidu,
I ran into this as well and submitted a pull request:

https://github.com/rails/rails/pull/2678

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:

https://github.com/rails/rails/commit/154081f0

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:

http://groups.google.com/group/rack-devel/browse_thread/thread/55f81ea198a2cc5f?fwc=2#f8ac46c9414cf038

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:

https://github.com/rails/rails/pull/2692

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

-john

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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.

/Jonas

On Fri, Sep 9, 2011 at 9:22 AM, Sidu Ponnappa <ckponnappa@gmail.com>
wrote:
> Hi,
>
> 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?
>
> Thanks,
> Sidu Ponnappa.
> http://c42.in
> http://blog.sidu.in
>
> [1] http://is.gd/c5wsjk
>
> --
> You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Hi John,

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

Best,
Sidu.
http://c42.in


On 9 September 2011 14:42, John Mileham <jmileham@gmail.com> wrote:
> >
> > Has anyone run into a similar issue?
>
> Hi Sidu,
> I ran into this as well and submitted a pull request:
>
> https://github.com/rails/rails/pull/2678
>
> 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:
>
> https://github.com/rails/rails/commit/154081f0
>
> 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:
>
>
>
http://groups.google.com/group/rack-devel/browse_thread/thread/55f81ea198a2cc5f?fwc=2#f8ac46c9414cf038
>
> 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:
>
> https://github.com/rails/rails/pull/2692
>
> With both applied to my fork of Rails, I''ve been happy with
> ActiveResource in 3.1.
>
> -john
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.