Rails core - Sep 2009 - Rack shouldn't insert session cookie in 304 response; problem inside iframe

Finishing up this head-banger... hope this is useful to someone
running a Rails 2.3.4 app inside an iframe.

My app runs in an iframe.  IE7 blocks my cookies .. and worse.. my
site.. if I render a page in that iframe without a P3P code.

So, I insert an appropriate P3P in the header of every response.  So
far, so good.

The problem is that I cannot insert a P3P into a 304 (not modified)
response.  Apache removes it... for good reason..  as the P3P in that
response violates RFC 2616 10.3.5 304 Not Modified.

Now the plot thickens.

IE7, when rendering an iframe, is ok with a P3P''less 304 header, as
long as there is no cookie-set.  Unfortunately, the middleware in
Rails 2.3.4 inserts a session cookie, even in the 304''s.  So, my
iframe''d application looses the user login as soon as he navigates
back to a previously rendered page.

I fixed this by inserting a new middleware component before the
cookiestore to override the default middleware behavior (see below).

I believe that the default middleware cookiestore should be modified
to not set any cookie in a 304 response.

Cheers
Robert

in environ.rb:
config.middleware.insert_before
ActionController::Session::CookieStore, "P3p"



in lib/p3p.rb
class P3p

  POLICY = ''CP="CURi ADMa DEVa IVAa IVDa CONi OUR IND DSP CAO
COR"''

  def initialize(app)
    @app = app
  end

  def call(env)
    response = @app.call(env)
    insert_p3p(response)
  end

  private

  def insert_p3p(response)
    if response[0] == 304
      response[1].delete(''Set-Cookie'')
    else
      response[1].update(''P3P'' => POLICY)
    end
    response
  end
end

On Sun, Sep 20, 2009 at 3:09 PM, Robert Vogel <pulcetto2001@gmail.com>
wrote:
>
> Finishing up this head-banger... hope this is useful to someone
> running a Rails 2.3.4 app inside an iframe.
>
> My app runs in an iframe.  IE7 blocks my cookies .. and worse.. my
> site.. if I render a page in that iframe without a P3P code.
>
> So, I insert an appropriate P3P in the header of every response.  So
> far, so good.
>
> The problem is that I cannot insert a P3P into a 304 (not modified)
> response.  Apache removes it... for good reason..  as the P3P in that
> response violates RFC 2616 10.3.5 304 Not Modified.
>
> Now the plot thickens.
>
> IE7, when rendering an iframe, is ok with a P3P''less 304 header,
as
> long as there is no cookie-set.  Unfortunately, the middleware in
> Rails 2.3.4 inserts a session cookie, even in the 304''s.  So, my
> iframe''d application looses the user login as soon as he navigates
> back to a previously rendered page.
>
> I fixed this by inserting a new middleware component before the
> cookiestore to override the default middleware behavior (see below).
>
> I believe that the default middleware cookiestore should be modified
> to not set any cookie in a 304 response.
This is kind of ironic, I just used Set-Cookie on a 304 response
intentionally last week to work around a caching issue :). It seemed
like a cool idea to me. If its strictly illegal to use Set-Cookie on
not modified I can understand the reason to patch the behavior.

However, I think the real problem with the "lazy" middleware is that
you can''t (easily) force no cookie to be set. I''ve been bitten
by this
too in 2.3. I''ve worked around it by doing a reset session in an after
filter (not ideal). We should find a way to restore "session :off"
behavior.

-- 
Joshua Peek

On a related note, I wanted to disable sessions globally on a  
stateless rails app. I managed to do this with:
      config.middleware.delete ActionController::Session::CookieStore
Not sure if this is better or worse than the after filter (or has the  
desired effect), but it may be useful.

On 20 Sep 2009, at 22:21, Joshua Peek wrote:
>
> On Sun, Sep 20, 2009 at 3:09 PM, Robert Vogel  
> <pulcetto2001@gmail.com> wrote:
>>
>> Finishing up this head-banger... hope this is useful to someone
>> running a Rails 2.3.4 app inside an iframe.
>>
>> My app runs in an iframe.  IE7 blocks my cookies .. and worse.. my
>> site.. if I render a page in that iframe without a P3P code.
>>
>> So, I insert an appropriate P3P in the header of every response.  So
>> far, so good.
>>
>> The problem is that I cannot insert a P3P into a 304 (not modified)
>> response.  Apache removes it... for good reason..  as the P3P in that
>> response violates RFC 2616 10.3.5 304 Not Modified.
>>
>> Now the plot thickens.
>>
>> IE7, when rendering an iframe, is ok with a P3P''less 304
header, as
>> long as there is no cookie-set.  Unfortunately, the middleware in
>> Rails 2.3.4 inserts a session cookie, even in the 304''s.  So,
my
>> iframe''d application looses the user login as soon as he
navigates
>> back to a previously rendered page.
>>
>> I fixed this by inserting a new middleware component before the
>> cookiestore to override the default middleware behavior (see below).
>>
>> I believe that the default middleware cookiestore should be modified
>> to not set any cookie in a 304 response.
>
> This is kind of ironic, I just used Set-Cookie on a 304 response
> intentionally last week to work around a caching issue :). It seemed
> like a cool idea to me. If its strictly illegal to use Set-Cookie on
> not modified I can understand the reason to patch the behavior.
>
> However, I think the real problem with the "lazy" middleware is
that
> you can''t (easily) force no cookie to be set. I''ve been
bitten by this
> too in 2.3. I''ve worked around it by doing a reset session in an
after
> filter (not ideal). We should find a way to restore "session
:off"
> behavior.
>
> -- 
> Joshua Peek
>
> >