all, tested with GlassFish Server Open Source Edition 3.2-SNAPSHOT (re-continuous), Build #9159 (14.08.2011 23:30:35), Revision: 48776
fix in GLASSFISH-17131 made now HTTP->HTTPS ccle working, but in HTTPS->HTTP traversal jsessionId is still lost; Can be viewed by the example app in GLASSFISH-17131;
Per discussion in http://java.net/jira/browse/GLASSFISH-17131 and the original description, I think you mean the scenario of http to https.
For https to http, there is a concern of exposing the cookies through url. That is why I do not encode the jsessionId in this case.
Hello Shing Wai,
you need to differ if the session was created in HTTP (1 = insecure session) or HTTPS (2 = secure session).
In case of HTTP created session (1):
-> user gets jsessionId, he may move on to https and also leave https to http side without loosing the session
In case of HTTPS created session (2):
-> user gets jsessionId, he may not leave from HTTPS and will loose his session there;
Currently any session traversal from HTTPS to HTTP will loose, independent of when it was created. The above described behaviour is also implemented exactly that way in other containers like Tomcat, Jetty and JBOSS as it immitates the behaviour from browser cookies. Those are only marked secure in case they were created within HTTPS space.
Currently one can't rely on glassfish URL rewriting as it will loose any insecure sessions in case of a HTTPS->HTTP traversal.
If you have any questions left or don't think that my arguments are valid just tell me
I have considered this scenario before. The question is how we know whether a session is secure (from https) or not. The information is not exposed from HttpSession.
One may require an interface change, at least the internal one, in order to achieve this.
Need further investigation.
regarding the differentation. Why don't you introduce a flag within the session, stating "boolean isSecureSession = false" and only set this true when session is created within HTTPS space. Then in case of HTTPS -> HTTP change you only look if the session is Secure and act accordingly.
This will workaround the issue. But then user can modified the flag in session.
The https issue can be resolved by adding secure attribute in internal Session interface.
Then we will face the issue as in GLASSFISH-17131.
In that case, a different port number (with same or different schema) is not enough to tell whether it is a redirect within the same server. In fact, it may be different server.
We will mark this as a duplicate of GLASSFISH-17131.