The question was asked the other day. Best idea we could come up with without actually trying was that a jsessionId is appended on the first time in as a precaution since full negotation regarding whether cookies are supported might not have been done yet.
Cookies are created by the server and sent to the client. If the client wishes to support cookies, it will then return the cookies on subsequent requests. The server may update some/all of them and send them back. Or delete them and not send them back, depending on application logic. In fact, the java.net Http request class automatically includes cookies when you emit HTTP requests from
Java applications without you even having to switch them on!
My thoughts on the randomCoder (For What They're Worth):
jessionId is probably no less secure than cookies, since the only real difference is that one is in the URL itself, but the other is in the attached content. If someone's intercepting, they can get one about as easily as the other. A far better bet is to make sure SSL is already running at that point, so that the whole thing's encrypted against man-in-the-middle attacks.
I certainly HOPE that modern-day search engines have the wit to discount the jsessionId part of a URL. Not to mention a lot of other chunder that frequently comes as part of the URL. After all, this isn't something new and unexpected.
He is right, on the URL rewriting however. If you expect to serve people who have cookies disabled (for paranoia or whatever reason), you MUST rewrite all URLs that you want to participate in the session. The first one that doesn't include jsessionid (meaning it wasn't rewritten) will break the chain.