In tracking down this bug https://issues.apache.org/jira/browse/WICKET-824 https://issues.apache.org/jira/browse/WICKET-824 which causes problems with browsers that have cookies turned off I've run into a more complicated issue.
The problem is that Tomcat will only add a session ID to a URL if you have called HttpServletReqest.getSession(true) since you can't add the session ID if there is no session. However this causes problems in wicket because a request starts out with a temporary session and only if needed is it bound. For example I had a page with 3 components on it 1) A first link 2) An image 3) A second link The first link was rendered with no session ID. However the second link did get a session ID added. The reason ended up being because the resource used by the image required a session and so it called Session.bind() before the second link was rendered. To fix this I changed WebRequestCodingStrategy.encode() to always call Session.bind() before encoding a URL just in case we need a session. However this may cause problems for developers who do not use sessions and don't want cookies and URLs with a ;jsessionid=XXX being sent back to browsers when it's not needed. Anyway, I can think of 3 possible fixes for this 1) Leave the patch as is and always start a session because just about everyone uses sessions anyway. 2) Add an API method like keepSessionTemporary() that can be called in a page constructor (or some other place) for those few developers who really don't want a session ID in their URLs. 3) Do a major overhaul to the wicket core so that URLs get encoded at the end of a request when it is known if a session is needed. I think this one would be way to much work though. Anyone have a better idea? -- View this message in context: http://www.nabble.com/Session-id-in-URLs-tf4525159.html#a12910755 Sent from the Wicket - Dev mailing list archive at Nabble.com.
