Hi, I''d like to get a few extra eyes on the patches in this ticket: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/2703 What they do is basically making the AbstractSessionStore not write out a new cookie whenever the session is accessed, only when the getter of the SessionHash is actually called (eg, when the session is modified). The other patch changes the way flash work as well, to not store an empty flash hash (which would modify the session hash). The motive behind this, apart from needless Set-Cookie headers, is that it makes expires_in and other Cache-Control directives work pretty much out of the box with proxy caches such as Varnish (assuming no cookies are set of course). Otherwise you''d have to mess around with keeping magic cookies (for logged in users etc) in sync, since basically everyone gets a cookie as it is today, which is a pain. I don''t use the CookieStore and I wasn''t sure if applying a similar approach as in the AbstractStore would break the encryption semantics (I got test failures on the persistent session_id tests). So it''s only the stores using the AbstractStore as a base (eg ACtiveRecordStore and MemcachedStore) who receives the above benefits. Cheers, JS
On Thu, May 28, 2009 at 8:15 PM, Johan Sørensen <johan@johansorensen.com> wrote:> The motive behind this, apart from needless Set-Cookie headersFWIW, a lot of people like sending Set-Cookie headers on every response, because it ensures you get punched through caches. Certainly, a significant number of apps don''t need that, but it''s something to bear in mind - I think we would not want to quietly turn off (most) Set-Cookie headers in an upgrade, IMHO it would need to be an option; otherwise people will upgrade and wonder why they''re suddenly having odd caching problems from crappy proxy servers. (Of course, HTTP itself has proper ways to deal with that - the varies headers etc.)