Messages
Reply
Edit
Delete02:58 pm
3Q40W3BI5
| From: | Rick Strahl |
| To: | Paul Mrozowski |
Hmmm... I have to look into that - I can't recall why the code does that. I think the idea was that ExpandScript should handle its own content type and headers and it gets its own response object.
However, as for the auth cookie that's special cased in ExpandScript, so no matter what it should pick up the cookie and use it a little further down (the cAuthSessionCookie logic).
+++ Rick ---
lEnableSessionState is automatically set to .T. inside of the Authenticate() method when the authentication method is "UserSecurity" or "Custom" so it doesn't have to be set here (and doesn't make any difference if it's set to .T.).
I see the session being created / written to the table, I see this being added to the Cookie collection, however the cookie is never written to the output stream. At the point ExpandScript is called, the session has been added to the table and the info is sitting in the Cookie collection. Then Response.ExpandScript is called. It sets the ContentTypeHeader to "NONE". It's never changed to anything else. That basically means when RenderHttpHeader() is called on Response, the cookie is never written to the output stream (since that code just returns w/o doing anything).
I can force it to work if I set a breakpoint inside of RenderHttpHeader and, the second time it's called (via CompleteResponse()) , force it to continue instead of returning (by bypassing the RETURN).
West Wind Technologies
Making waves on the Web
