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

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.

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.