Issue Details (XML | Word | Printable)

Key: GLASSFISH-17191
Type: Sub-task Sub-task
Status: Closed Closed
Resolution: Duplicate
Priority: Blocker Blocker
Assignee: Shing Wai Chan
Reporter: KBachl
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

jsessionId is lost while redirecting from https to http

Created: 15/Aug/11 11:57 AM   Updated: 26/Aug/11 02:08 AM   Resolved: 26/Aug/11 02:08 AM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified


all, tested with GlassFish Server Open Source Edition 3.2-SNAPSHOT (re-continuous), Build #9159 (14.08.2011 23:30:35), Revision: 48776

Participants: KBachl and Shing Wai Chan

 Description  « Hide

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;

Shing Wai Chan added a comment - 19/Aug/11 04:08 PM

Per discussion in 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.

KBachl added a comment - 20/Aug/11 02:52 PM

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


Shing Wai Chan added a comment - 24/Aug/11 04:59 AM

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.

KBachl added a comment - 24/Aug/11 02:58 PM

Hello Shing Wai,

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.

Shing Wai Chan added a comment - 24/Aug/11 04:21 PM

This will workaround the issue. But then user can modified the flag in session.

Shing Wai Chan added a comment - 26/Aug/11 02:08 AM

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.