This project is archived and is in readonly mode.

#5777 ✓stale
Christopher Meiklejohn

Rails 3 Session Cookies and Render Calls

Reported by Christopher Meiklejohn | October 10th, 2010 @ 06:17 AM

In rails 3.0.0 I've noticed that calling render :nothing => true doesn't return a set-cookie header, where if I have a blank ERb file, it does. The documentation here: http://guides.rubyonrails.org/layouts_and_rendering.html, seems to indicate that the set-cookie header should be being returned.

Can someone else attempt to reproduce this problem?

For now, in my controller I'm explicitly calling session[:foo] = "bar", which is forcing the cookie to be returned. If I remove this and put a blank erb template in and call format.html, that also returns the header.

Comments and changes to this ticket

  • Álvaro Bautista

    Álvaro Bautista October 10th, 2010 @ 10:31 AM

    I tried to reproduce it, but it works fine for me. Having the following action:

    def nothing
      session[:is_there] = "anything wrong?"
      render :nothing => true
    end
    

    a request (curl -i http://localhost:3000/site/nothing) responds with:

    HTTP/1.1 200 OK 
    X-Ua-Compatible: IE=Edge
    Connection: Keep-Alive
    Content-Type: text/html; charset=utf-8
    Date: Sun, 10 Oct 2010 09:23:46 GMT
    Server: WEBrick/1.3.1 (Ruby/1.8.7/2010-05-25)
    X-Runtime: 0.017131
    Content-Length: 1
    Cache-Control: no-cache
    Set-Cookie: _wadus_session=BAh7ByIPc2Vzc2lvbl9pZCIlY2I2NzEyNjkyOWJjZDEzYWI2ODljZjNkMTc3YzRiNDgiDWlzX3RoZXJlIhRhbnl0aGluZyB3cm9uZz8%3D--6654eb669d37414ee7d62bfcd63fdf1898a26427; path=/; HttpOnly
    

    The guide recommends using the head method instead. I think the :nothing option is still there for compatibility with rails 2.

  • David Trasbo

    David Trasbo October 10th, 2010 @ 02:44 PM

    • State changed from “new” to “incomplete”
    • Importance changed from “” to “Low”

    Álvaro,

    I think you misunderstood. The bug is that if you don't explicitly set a session value, the Set-Cookie header will not be present in the response when using render :nothing => true. It should, because if you, as pointed out, make a blank template instead, the Set-Cookie will be present, regardless of whether or not you set a session value.

    I was able to confirm this using edge Rails:

    $ script/rails g controller people index
    ...
    

    app/controllers/people_controller.rb:

    class PeopleController < ApplicationController
      def index
        render :nothing => true
      end
    end
    

    config/routes.rb:

    Ticket5777::Application.routes.draw do
      resources :people
    end
    

    Response:

    $ curl -i http://localhost:3000/people
    HTTP/1.1 200 OK 
    Content-Type: text/html; charset=utf-8
    X-Ua-Compatible: IE=Edge
    Etag: "7215ee9c7d9dc229d2921a40e899ec5f"
    Cache-Control: max-age=0, private, must-revalidate
    X-Runtime: 0.024136
    Server: WEBrick/1.3.1 (Ruby/1.9.2/2010-08-18)
    Date: Sun, 10 Oct 2010 13:42:05 GMT
    Content-Length: 1
    Connection: Keep-Alive
    

    Please provide a patch (https://rails.lighthouseapp.com/projects/8994/sending-patches) with a fix and/or a failing test.

  • Andrea Campi

    Andrea Campi October 12th, 2010 @ 07:31 AM

    -1

    I think you misunderstood. The bug is that if you don't explicitly set a session value, the Set-Cookie header will not be present in the response when using render :nothing => true. It should, because if you, as pointed out, make a blank template instead, the Set-Cookie will be present, regardless of whether or not you set a session value.

    I think that's the intended behavior: at some point in the past, session creation became lazy, so if you don't use one (not even for csrf) no cookie should be sent.

    You can verify that by rendering an empty template: you will get the cookie iff you have csrf_meta_tag in your layout; you will not if you comment that out.
    In fact, the same will happen if you force layout rendering, even for @render :nothing@:

    render :nothing => true, :layout => true
    

    Besides, as Alvaro mentioned, render :nothing is a compatibility shim for @render :text => nil@, and a better alternative exists in head :ok.

  • Christopher Meiklejohn

    Christopher Meiklejohn October 12th, 2010 @ 04:36 PM

    This problem also occurs when using send_data, to send something like an image back. What is the desired way to force a cookie to be set?

  • Álvaro Bautista

    Álvaro Bautista October 12th, 2010 @ 05:56 PM

    Well, I did misunderstood. ;)

    However, I don't see any problem at all.

    If you take a look at the test file for cookie stored sessions [http://github.com/rails/rails/blob/master/actionpack/test/dispatch/...] you'll see the following test cases:

    • test_doesnt_write_session_cookie_if_session_is_not_accessed
    • test_doesnt_write_session_cookie_if_session_is_unchanged

    When you render the erb template, is your layout calling csrf_meta_tag? If so, then you are changing the session value for _csrf_token. When you use the nothing option or the head method without explicitly changing the session, then there is no need to send back the session cookie. The same should occur with send_data.

    What do you think? Would this be the right answer?

  • Ryan Bigg

    Ryan Bigg October 19th, 2010 @ 08:27 AM

    Automatic cleanup of spam.

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:48 PM

    • State changed from “incomplete” to “open”

    This issue has been automatically marked as stale because it has not been commented on for at least three months.

    The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.

    Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.

  • Santiago Pastorino

    Santiago Pastorino February 2nd, 2011 @ 04:48 PM

    • State changed from “open” to “stale”
  • bingbing

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

Pages