Phew, the last 24 hours or so have been a bit of a nightmare.
Beware: what follows probably affects a tiny number of people and will likely be tedious and largely irrelevant as far as the majority of the population of the world is concerned. If you don’t know what the phrase ‘third-party cookies’ means, you should probably stop reading now. However, if you’re planning on using third-party cookies then you might find this article useful.
As you should already know, all third-party cookies are blocked by the default (Medium) setting of Internet Explorer unless they carry a compatible compact P3P header. Which is just fine: that’s what P3P is for.
However, we stumbled across a problem. We’d set up our system with the P3P policy in place and everything seemed to work to start with. Then it all went horribly wrong: on an apparently random basis, IE decided to block the cookies we were setting. Some pages would be OK, others not. It was all extremely frustrating.
To cut a long story short, and thanks to a great deal of hair-pulling and detective work by my colleague, the problem became clear.
It so happens that the third-party domain we’re using to carry the cookie is also being used to serve other content — in fact it’s the domain where those who have subscribed to the project we’re working on can view and update their personal information. It turns out that the problem was caused by other files originating on that domain without a P3P header. The lack of the header on these files seemed to nullify the P3P on the file that carried the cookie, and prevent those cookies being processed correctly.
So we used Apache’s mod_header to ensure that all files served on the third-party domain carry the same P3P header and bingo! all was fixed. My colleague is now enjoying an extended cigarette break and we’re all breathing a sigh of relief that we don’t have to completely rethink our cookie-propagation technology.