Updates on problems with J2EE Sessions

I mentioned recently that I'd done an article in the CFDJ on using J2EE sessions. Since then, I've learned of a few challenges that can make working with them difficult in certain circumstances.

First, when you enable J2EE sessions, CFMX no longer creates the variables session.cfid and session.cftoken. If you're using those to attempt to persist sessions when (or in case) cookies aren't supported, those values are no longer available once you enable J2EE sessions.

You might think to try to use the available session.URLToken variable instead (or cookie.jsessionid, which does exist on the server while the page is being executed). Unfortunately, nether of these will work.

CFMX can only receive a jsessionid on a URL if it's appended after the filename and extension as ;jsessionid=nn, a format that was discussed in the article. This is the reason for the URLSessionFormat function, which was also discussed in the article. But that has problems as well.

I had mentioned in the article that the new URLSessionFormat would, when when using J2EE sessions (and when the browser does not present the JsessioID cooke), cause the resulting URL it generates to appear in the format templatename.cfm;JSESSIONID=8030949691025145133137. Note that the JSessionID is appended to the filename separated by a semicolon, rather than to the query string.

I added that "Still, when that's happened, the URL has functioned as expected."

Well, I was doing testing at the time on the built-in CFMX web server. I've since discovered that if you're doing this on an IIS web server, the use of the ;jsessionid after the filename causes a 404 file not found. This is disappointing.

If you use J2EE session variables and are working under an IIS web server, don't use the URLSessionFormat, at least until this problem is resolved by MM (or MS).

And that's not all. If you enable J2EE sessions and then use CFLOCATION, and a browser executes the page but doesn't support cookies or doesn't present the JsessionID such as on the visitor's first visit, CFMX will append the ;jsessionid after the filename and extension as discussed in the article. That's great for the built-in CFMX web server.

Unfortunately, if the redirection is to an IIS server (whether yours or another), the request will fail. Even using the ADDToken="no" won't stop it doing this.

Either MM needs to address this, or Microsoft needs to change IIS to allow this sort of URL.

And for final clarification, in case you missed it above, this issue of how URLSessionFormat or CFLOCATION determines whether to append the needed sessionid info is done not based on whether the browser supports cookies or not (CF can't really tell that), but it's simply a question of whether the expected sessionid cookie is passed: if J2EE sessions are enabled, it looks for a JSessionID cookie, if they're not, then it looks for the CFID and CFTOKEN cookies.

Not only will they not be present in a browser that doesn't support cookies but also they won't be there on the very first page that the user visits even if they do support cookies. These issues above could bit you then.