X-Frame-Options and etagify prevent iframes we serve from working

[lloyd]

I believe this to be a blocker for train-2012.03.28, one that will warrant a hotfix:

Our middleware is layered in such a way that X-Frame-Options: DENY is appended to every response at a very early stage in request handling and specific views that serve content intended to be served in iframes removes this header.

We recently included the etagify library, which is registered before individual views are rendered and returns a 304 when ETag headers allow.

Because etagify interrupts the request handling and serves an early 304, requests for HTML which should not have X-Frame-Options headers, has them in the case that the client has an up to date cached version of the resource.

For Chrome on MacOSX at least, the X-Frame-Options header served when the client has an up-to-date cache prevents any of our iframes from working.

You can reproduce this issue probably by using IE8/9 (which relies on the "relay" iframe) or by trying to use 123done.org, which relies on the "communication" iframe.

User visible manifestation is that BrowserID doesn't work.

[ozten]

Unable to repro against a local server (dev branch) with IE 9 on Windows Vista SP 2.

Will try 123done.org.

[ozten]

Cool, I got an error via 123done.org
'We are very sorry, there has been an error!
Please close this window and try again.
Action: Setting whether the user owns the computer"

Fx 12.02a on Mac OS X

[ozten]

Swarmified, closing.

[jrgm]

Verified on stage (diresworb.org) for IE8/winxp, IE9/win7, Chrome/OSX, FF/OSX ability to sign_in and repeat with cached values via beta.myfavoritebeer.org.

Also by direct inspection of the request/response on initial load and soft reload of stage diresworb.org /relay and /communication_iframe with FF11 on osx.

I can also use 123done.org, although not on IE8 which is codepo8/123done#1