Tomcat Session is not working when accessed from ssl?

[Vincent Senese]

I am so puzzled.
The bellow code works perfect when I am accessing from http, but when I access from ssl I cannot retrieve the listener using this (FileProgressListener) session.getAttribute("FileProgressListener");

Again works fine not in ssl, anything I am doing incorrectly that is obvious?

		if(!ServletFileUpload.isMultipartContent(request))
		{
			out.println("Nothing to Upload");
			
		}
		FileItemFactory itemfactory = new DiskFileItemFactory();
		ServletFileUpload upload = new ServletFileUpload(itemfactory);
	 
		FileProgressListener lis = new FileProgressListener();
		upload.setProgressListener(lis);
		
		HttpSession session = request.getSession();
		session.setAttribute("FileProgressListener", lis);

[Tim Holloway]

Welcome to the JavaRanch, Vincent!

Tomcat handles sessions just fine in both HTTP and HTTPS modes. But when Tomcat switches from HTTP to HTTPS, it changes the value of jsessionId, so if you have code that's pulling jsessionid from either URL or cookie and trying to do things with it - don't.

One thing I do recommend when obtaining the HttpSession object is not to use the no-argument form of the call. It's the same thing as calling "getSession(true)", which means that if a session didn't exist before the call, one will be created. And it will be empty. If you call getSession(false), then the call will return false if the session doesn't exist and that will be a warning to you that something isn't what you think it is.

[Vincent Senese]

Thanks for the info...

Basically I don't get what it can be then.

I built this app for someone and just tried using ssl and no issue as you said it would work.

When I access the box directly via IP address it works (I connect via http), but when using the domain myapp.mydomain.com it goes to https which is fine but session variables don't work at that point. Is it possible the proxy that directs to the internal box is blocking something?

For instance if the ajp port was blocked on the proxy could that prevent something, I'd think not, but I'm grasping at straws:(

[Tim Holloway]

Two things domains don't do: You cannot define a port in Domain Naming Services (DNS). You cannot define a protocol in Domain Naming Services (DNS). DNS only knows names and IP addresses.

The choice of port and protocol is determined by the URL in the client. By convention, if your client submits a URL request beginning with "http:" with no port override following the server name/IP, then the client will encode as plain text and send to the server's port 80. If your client submits a URL request beginning with "https:", it will SSL-encode the request and direct it to server port 443.

Session IDs are not affected by any of this. The jsessionid forms a name/value pair whose name is "jsessionid" and whose value is (theoretically) randomly generated. That value is then used as a hash key at the server end to retrieve the HttpSession object pertaining to that user and make it available on request by the webapp.

The jsessionid is continuously passed back and forth from client to server, since, as I mentioned previously, the actual jsessionid value can change without notice - it's just a hash key and the server can refile the HttpSession under a completely different hash key any time it deems appropriate.

This back-and-forth mechanism has 2 possible implementations: cookies or URL rewriting. Cookies are the cleanest way. Cookies are automatically handled by the client and server with no user coding required. And if a user manually types in a URL for a host that has a session cookie, it will automatically be included in that manual URL request.

But sometimes cookies aren't an option. Sometimes users may have configured their clients to ignore cookies. Sometimes you're operating in an environment where cookies are forbidden. In that case, you have to resort to URL rewriting.

URL rewriting is done in J2EE using the HttpServletResponse urlRewrite method. This method takes a model URL and appends the current sessionid to the end to produce a session-sensitive URL that will looks something like this: "http://myserver.com:1234/mywebapp/mydir/myresource?param=X&param1=y;jsessionid=f1skf3s8"

In other words the ";jsessionid=" part is appended to the original URL. I showed a random port number, but in fact the port number was just to demonstrate that override port numbers are just as possible on rewritten URLs as they were on the original model URL.

So, armed with that information, what you need to determine is whether or not your proxy is losing the jsessionid or if you are not ensuring that it is being passed back and forth.

A properly-configured proxy will not be touching the cookies (unless you explicitly add cookie rewriting directives!) and should not be removing things (specifically the ";jsessionid=") from the proxy-translated URL. Whether your're talking localhost or remote connections, named servers or IP addresses, these charateristics and constraints remain the same.