I guess the only alternative left with us would be to force users to enable cookies in IE as MS is not going to address this issue when it has many on its plate. As far as MM is concerned, lets wait for the next release, something should come up.

I'd like to add a couple more observations about using J2EE sessions.

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, niether 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 the caveats above explain why that's problematic in an IIS environment.

And it turns out that the problem above is even larger than I first learned.

If you enable J2EE sessions and then use CFLOCATION, and a browser executes the page but doesn't support cookies or doesn't present any to the page, 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.

I had mentioned in the article that the new URLSessionFormat would, when when using J2EE sessions, cause the resulting URL it generates to appear in the format templatename.cfm;JSESSIONID=803094969 1025145133137. 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. (The problem really ought to be solved by MS.)