If I render a partial from a controller in a brand new rails 3.2.2 app then the following content type is returned:
Content-Type: ; charset=utf-8
To reproduce, start with a new rails app:
rails new foo
Add a resource
./script/rails g resource person
Fill in the PeopleController as suggested in #5025
class PeopleController < ApplicationController
render partial: 'james', formats: :html
Add content to the partial
⚡ cat app/views/people/_james.html.erb
Load the action:
⚡ curl -v http://127.0.0.1:3000/people
* About to connect() to 127.0.0.1 port 3000 (#0)
* Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 3000 (#0)
> GET /people HTTP/1.1
> User-Agent: curl/7.24.0 (x86_64-pc-linux-gnu) libcurl/7.24.0 OpenSSL/1.0.0g zlib/1.2.6 libidn/1.23 libssh2/1.2.8 librtmp/2.3
> Host: 127.0.0.1:3000
> Accept: */*
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Content-Type: ; charset=utf-8
< X-Ua-Compatible: IE=Edge
< Etag: "cb058f946972a4d5413cfee068e298cf"
< Cache-Control: max-age=0, private, must-revalidate
< X-Request-Id: 9089271888581c058a8d3228067b7e1f
< X-Runtime: 0.002992
< Content-Length: 19
< Server: WEBrick/1.3.1 (Ruby/1.9.3/2011-10-30)
< Date: Fri, 02 Mar 2012 02:42:48 GMT
< Connection: Keep-Alive
* Connection #0 to host 127.0.0.1 left intact
* Closing connection #0
Here's my environment details:
⚡ ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
⚡ rails -v
⚡ bundle -v
Bundler version 1.0.22
⚡ uname -a
Linux gaz 3.2.0-1-amd64 #1 SMP Tue Feb 28 15:35:32 UTC 2012 x86_64 GNU/Linux
I could reproduce it in a bare controller with render :partial => 'partial' as well:
render :partial => 'partial'
$ curl -LI http://localhost:3000/test/partial
HTTP/1.1 200 OK
Content-Type: ; charset=utf-8
DAMN. dude, sorry for wiping your post :( Sorry, I was 99 percent sure github at least checks for owner... but He doesnt :( What a bug-day
Yup, this can be easily reproduced also in tests, I'm checking it
Fix #5238, rendered_format is not set when template is not rendered
@yob please check it out that the commit fixes the issue
Yep, this seems to work as expected on the 3-2-stable branch
Will this fix be in the next Rails release?
I encountered the same problem.
The only difference in my case is that I didn't specifiy formats: :html explicitly. But it should default to text/html anyway when rendering an .html partial, or? Some information on that, would be very much appreciated.
I would like to test if the patch above would fix my problem, however I'm not quite sure on how I would do that. Is there by chance any guidance on what I would need to do?
@jhilden please test pointing to 3-2-stable branch in your Gemfile ...
gem 'rails', :git => 'git://github.com/rails/rails.git', :branch => '3-2-stable'
And let me know if everything works for you.
Thank you for your guidance @spastorino. I installed rails from the 3-2-stable branch just as you told me and it seems to have fixed the incorrect content-type in the browser (where the problem first surfaced, using jQuery.ajax() + Firefox).
:formats => :html
In my controller I'm just doing a render :partial => "places/guest_calendar" where the partial is of type .html.haml. And this is my test case:
render :partial => "places/guest_calendar"
class CalendarsControllerTest < ActionController::TestCase
context "show" do
should "succeed" do
xhr :get, :show, :place_id => @place.to_param, :for_date => Date.today.beginning_of_month.to_s
# puts request.inspect
# puts response.headers
When comparing the HTTP headers of the two different XHRs (from Firebug and from the request object in the test case) I noticed that in the browser the request's HTTP accept header was just */* while in the test case I got this from the request object:
@jhilden does this commit looks like something that should fail? It passes for me and I'm not sure what's the difference from your app.
@drogus I tried it with curl and it's correctly returning text/html. You can find the full output here https://gist.github.com/2213884 Thank you very much for your help.
Do you have any idea what could be the problem/difference in my test? Is there a way to look at the pure HTTP request header (besides the stuff in the request object)?
@jhilden actually I found the problem and it's not only the matter of test. It will fail when you also make it xhr request (in a way that rails understands it) -H X-Requested-With: XMLHttpRequest. I fixed it here: #5603
-H X-Requested-With: XMLHttpRequest
Could you confirm that your test now does not fail on fresh 3-2-stable?
@drogus now it works with the latest 3-2-stable Thanks a lot!