On Thu, 13 Apr 2000, Curtis Maloney wrote:
When you log in in this circumstance, two cookies get set (once for the verify page, once for the page it redirects you to).
This is what I expected as long as the two cookies have the same SessionUID. If not then that is the problem.
So.. If the cookie means it IS commiting, i'm left wondering why the information isn't showing up. When a redirect occurs, is it possible the browser is making the new request on another thread, which _sometimes_ beats out the 'commiting' thread? Or is commiting completed before the cookie is set?
As far as I understand calling RESPONSE.redirect, causes the RESPONSE object to emmit the neccessary headers for redirection. In other words the transaction has already finished, commited, and the client receives the redirection headers before the client places the next request. The redirected request can be served by any thread. Nevertheless as the original transaction has already commited the FSSession data should be available to the new request. I have recreated your set up (if I am off let me know) and it works fine for me. My standard_html_header looks like: <HTML><BODY> <dtml-call FSSession> <dtml-if "FSSession.has_key('test')"> <P><dtml-var "FSSession['test']"> </dtml-if> <dtml-if flag> <dtml-call "FSSession.set('test','Hi')"> <dtml-call "RESPONSE.redirect('method2')"> </dtml-if> and my method1 and method2 contain <dtml-var standard_html_header> nothing <dtml-var standard_html_footer> if I call /Test/method1?flag=1 I get redirected to /Test/method2 which displays Hinothing as expected. Check if the two SessionUIDs in the two cookies match or use showSession in the FSSession directory to examine the contents of the session file. Regards Pavlos