|IE6, p3p, frames & 3rd party cookies|
pages won't serve in someone else's frameset
| 5:35 pm on Mar 13, 2002 (gmt 0)|
We're a totally reputable site served over https and we have a p3p policy.
The problem appears to derive from our architecture - we run a number of distributed sites where we re-purpose our content for partners. We serve all these pages from the same URL, but we use a cookie to determine which distributed site the viewer should be looking at.
Roughly what happens is this: when we repurpose content, we give our partner a URL like https://www.domain.com/site/partnername/. When a browser hits that page it sets a cookie that lets our servers know they should be receiving the <partnername> version of our content. Subsequently, the URL that the user sees resolves to https://www.domain.com/ and the server pre-pends all the relevant paths to serve up the right stuff.
The issue comes when our partners serve those pages in frames and our cookie then becomes a third-party cookie (that is served from a different site than the site serving the frameset). At that point IE at default security setting won't serve our page before seeing the p3p statement.
Catch 22 is that we can't serve a page until the browser's got a cookie & as we haven't served a page the browser doesn't have our p3p statement. Therefore IE6 blocks the page and users get caught in a loop and never see anything.
Has anyone got experience of this issue, or got any thoughts on how to circumvent it? Although there's quite a bit of talk around p3p and IE6 on newsgroups, we haven't seen this issue directly referred to before. We also can't find any official Microsoft advice.
Finally, here comes the science bit:
here's what we send to the server. the lines numbered 1,2,3,4,5,6,7 are info sent back we say it's a redirect, we tell the P3P (compact) policy, we tell the new location, set the cookie name=value but IE6 replies without the cookie.
wget --load-cookies=cookies.txt --save-cookies=cookies.txt --server-response https://192.168.0.42:10122/
Connecting to 192.168.0.42:10122... connected.
HTTP request sent, awaiting response...
1 HTTP/1.1 301 Moved Permanently
2 Date: Wed, 13 Mar 2002 16:07:33 GMT
3 Server: Apache Ben-SSL IHM
4 Set-Cookie: sw=bd3aa6cd7cebdab57c9857f8791369c9; expires=Thursday, 13-Mar-2003 16:07:33 GMT; path=/;
5 P3P: P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo"
6 Location: /
7 Connection: close
8 Content-Type: text/html; charset=iso-8859-1
Location: / [following]
| 10:38 am on Mar 15, 2002 (gmt 0)|
I don't have a final answer, but one place to look for a method, is to the banner companies. Take a look at how DoubleClick, Burst, and other ad servers are using p3p. Sometimes that is within iframes (such as SkyScrapper ads).
If anyone would have p3p vs frames vs cookies figured out, it would be them.
| 12:33 pm on Mar 15, 2002 (gmt 0)|
The last time I wrote and asked about this issue I received the following;
Add the HTTP header with the compact policy.
I wrote again as that doesn't quite cover the problem. The specifications originally didn't require a compact policy at all and the W3C hasn't been forthcoming with a reply.
I'll see what Kioche has to say as there are a lot of people waiting for a definitive answer for this.