The problem is this - after the user enters their username and password and submits the login form (which redirects to j_security_check), the ensuing redirected request does not contain this cookie on the server side. I've verified this by placing a breakpoint at the very top of the servlet handling code, and inspecting the contents of the HTTPRequest object. This object does not contain the headers or any of the cookies that you'd expect to see coming in from the client side.
Interestingly enough, if the user logs out and (optionally) closes the browser, this cookie does appear in the request the second time they submit to j_security_check. At this point, I'm betting it's some strange semantics with the way that j_security_check works.
I know that it's supposed to preserve all headers and cookies from the *original* request (the one that initially redirected to login.jsp due to the attempt to access a protected resource). This makes sense, since with a clear browser cache, the timezone offset cookie does not exist until after the user has been redirected to the login.jsp page, and thus the original request would not contain the cookie, only the POST to j_security_check.
My question is this - how can I preserve all of the headers and cookies that were submitted in the j_security_check POST request to stick around and be transferred to the ensuing redirected request after a successful post to j_security_check?
A little data on our app - we're running on JBoss AS 4.0.5. Also, another interesting data point - this works as expected on two other not-to-be-named J2EE app servers. Is JBoss doing the right thing with this request and the other two are broken, or is it the other way around?