问题
I have an application that I'm hosting on a local environment and am experiencing a very strange problem that occurs only in IE. The other browsers I've tested with (Chrome and Firefox) don't seem to reproduce the problem.
I'm using Wicket 1.5.0 snapshot.
In the application I've got a dispatch page that validates initial requests and take further action upon validation. In it I've got:
setResponsePage(Canvas.class, pageParams);
MyCustomSession.get().bind();
and in Canvas page upon calling MyCustomSession.get() it returns a brand new session for each and every request, which causes problems because all the data I've previously put in the session is gone.
Then I traced down the problem and to me it looks like IE always sends the very same jsessionid in request header, no matter what - 8302844E8BB8FD6D1A617C0E6A2C58C3.
In the response headers for setResponsePage(Canvas.class, pageParams), with status code of 302 I saw the response headers as follows:
Set-Cookie JSESSIONID=91474844FC17D16B960A0760BA9DC129; Path=/apppath
Regardless of that all next requests from IE have that header field (the same session id as before):
Cookie JSESSIONID=8302844E8BB8FD6D1A617C0E6A2C58C3
Please assist me to resolve this because it really bothers me. Thanks!
回答1:
Actually the problem was that cookie was not sent at all. I examined further and it turned out it is a problem of third-party content communication (as IE terminology would define that).
Our application is a FB application and is therefore contained within an iframe (since being embedded by FB) and IE's security settings were refusing to send cookie to our - in this case - third party content. After some research I found out that putting P3P (Platform for Privacy Preferences Project) header in our responses would satisfy these policies and enable IE to send cookie in the request headers.
For this purpose, I created a filter in our web project to put that header in each response being sent from our app.
回答2:
Basically just a wild guess: Is there a JSESSIONID cookie stored for the path / of the same domain in the browser which produces this strange behavior? Maybe IE sends this cookie instead of the one stored for /apppath.
Somewhere in the back of my head I seem to remember a similar problem, but unfortunately I can't really remember the solution...
来源：https://stackoverflow.com/questions/10139364/ie-always-sending-the-same-jsessionid-over-time-using-java-wicket