- From: Henning Michael Møller Just <henning.just@datagraf.dk>
- Date: Tue, 20 May 2008 13:12:55 +0200
- To: <www-p3p-policy@w3.org>
Hi there Just joined this list after searching the archives. I couldn't find an answer to the question I am going to present here, but that may of course just be me :-) I have two clients with a fairly similar setup when seen from the user's perspective. They have a SSL site with a webpage. On this webpage they have an iframe referring to my site. Their site tries to set a cookie (an ASP session cookie I think) and my site tries to set a cookie. In case (A) there are no problems. This was the first site so I was happy and thought I had the situation under control :-) In case (B) the cookies were blocked in IE7 (and IE6). Not just my cookie but also their cookie. I didn't know about P3P before this but read up on it and finally figured out how to make a proper policy for my site. When my cookie still didn't work I figured out how to make a compact policy and added it to the header. Then the cookie worked for my site. In both cases the client sites has a /w3x/p3p.xml file, but they are 1) almost identical and 2) has syntax errors in the <COOKIE-INCLUDE>. There's no P3P: header in the HTTP headers and there's no P3P compliant <link> element, so http://www.w3.org/P3P/validator.html cannot find a valid policy reference file. In case (A) I am not providing any P3P information. No reference file, no compact policy. In case (B) I am now providing the information, but before doing that it didn't work. This is my question: Why does it work in case (A) but didn't in case (B)? What else do I have? Let's see.... In case (A) the client site tries to set a cookie (and succeeds) that looks like this: Set-Cookie: ASPSESSIONIDQCACCTAT=LOHLOLNAKMCGECOHPECEABIJ; path=/ In case (B) the client site tries to set a cookie (and is blocked) that looks like this: Set-Cookie: ASP.NET_SessionId=ml504ruu0sazyhuqd0lvhm45; path=/; HttpOnly In case (A) the iframe has src set to the https:// path for my site. In case (B) the iframe has src set to the http:// path for my site (giving the user a horrible warning about viewing secure and insecure items). My site then redirects to https:// I *think* that explains why the address bar in case (A) has a lock on a bright blue background to the right, while in case (B) no such lock (no pun intended ;-) I hope I make sense with all this - and I know it works now and I ought to be happy, but I want to know why it didn't work before. Otherwise it will just become a magic potion I'll have to apply every now and then :-( Best regards Henning Michael Møller Just
Received on Tuesday, 20 May 2008 13:17:15 UTC