Question

I notice that the first time a user visits my site the Wicket-generated URLs contain a jsessionid, rather than relying on the cookie for session information.

The cookie does get set successfully, and if the user simply reloads the page, the jsessionid is no longer appended to the URLs. You can test this out here: pixlshare.com. Hovering over any of the image links will show a URL with a jsessionid; reload the page, and the jsessionids will be removed.

From previous experience with the Wicket SEO page I know how to remove the jsessionid to hide it from bots, but employing this technique for regular users seems like a hack. It will also break the site for those people paranoid enough to have cookies disabled.

This is happening after a recent move to Tomcat from Glassfish, though I can't say for certain that that's the cause. Also, I'm using Apache's mod_proxy in front of Tomcat.

Was it helpful?

Solution

Here's what happens: the client requests a page for the first time, sending no cookies at all:

$ curl -v http://pixlshare.com/upload

The server does not know anything about client capabilities based on this request, in particular whether it supports cookies or not. Hence, to be extra safe, it sends both cookie and JSESSIONID encoded in the URL:

< Set-Cookie: JSESSIONID=25E7A6C27095CA1F560BCB2983BED17C; Path=/; HttpOnly
...
<a wicket:id="image1Link" href="gallery/OKfzVk;jsessionid=25E7A6C27095CA1F560BCB2983BED17C">

In other words the servlet container defensively appends JSESSIONID to every URL, just in case the client does not support cookies.

So why the JSESSIONID disappears on the second request? Because now the client sends the cookie in HTTP request and the server knows, that the client handles them. That being said, JSESSIONID is no longer needed.

$ curl -v -b JSESSIONID=25E7A6C27095CA1F560BCB2983BED17C http://pixlshare.com/upload
> Cookie: JSESSIONID=25E7A6C27095CA1F560BCB2983BED17C
...
<a wicket:id="image1Link" href="gallery/OKfzVk">

On the other hand if the client does not support cookies, server will continue to rewrite URLs.

This is not a Wicket issue, this is a Tomcat feature.


BTW (from your website JavaScript):

path = path.replace(/^C:\\fakepath\\/i, '');

What the f...ake?

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top