[Zope] Help with session data and redirects

[Chris McDonough]

That makes me suspect that something about PCGI or IIS is not passing
along the session's set-cookie header to the browser in the initial
redirect response.  You may want to use something like (under UNIX or
Cygwin):

wget -S
http://your.servers.pcgi.hostname/createSessionAndRedirect?sessionText=foo

This will print the headers of the response (you may want to do this in
a temp directory, it also saves the files).  If you don't see a
set-cookie header, something is stripping it out.

It works the "second time around" because the set-cookie header is sent
in the response that contains the rendered view_session_obj.pt script
(as a result of accessing REQUEST.SESSION in that script).  Thereafter,
the browser sends a cookie header along with every request.

So if you can verify this, the bug becomes "set-cookie headers are not
passed along to browsers when PCGI and/or IIS is used and the response
also contains a redirect header".  Not that I know how to solve this,
but at least we could have a hypothesis. ;-)

- C

On Tue, 2003-04-15 at 12:36, Brad Powell wrote:
> Zope 2.6.1 running under IIS on a Windows 2000 Server, with PCGI.
> Client browser is IE v5.50.4522.1800 running on Windows 2000 Professional. 
>  Also tried with Mozilla 1.0 under Debian.
> 
> Gathering this info for you made me think about the PCGI interface, and I 
> discovered something interesting.  The redirect works great when I'm going 
> direct to Zope port 8080 (not using PCGI).  It manifests the initial 
> request problem when using the PCGI interface.  In fact, that's why 
> Konqueror worked.  I was going direct to port 8080 when I was trying 
> Konqueror.
> 
> Brad
> 
> 
> 
> 
> 
> Chris McDonough <chrism@zope.com>
> 04/15/2003 11:12 AM
> 
>         To:     Brad Powell/PPCO@Phillips
>         cc:     zope@zope.org
>         Subject:        Re: [Zope] Help with session data and redirects
> 
> 
> I'm afraid I can't reproduce this behavior.  Which
> browser(s)/platform(s) does it occur under?
> 
> On Tue, 2003-04-15 at 12:06, Brad Powell wrote:
> > Thanks, Chris, for the quick reply.  I tried both of your suggestions: 
> the 
> > random query string and the setHeader statements in the ZPT.  They both 
> > improved the situation in that requests after the initial one are now 
> > returned properly.  However, the very first request still returns the 
> "Problem: no session object (redirectTest)" message.  By the way, instead 
> of a response.redirect, if I return the page 
> > template directly in the script with a statement like "return 
> > container['view_session_obj.pt']()", it works perfectly.  Unfortunately, 
> I 
> > need the redirect because of the way my actual page template works.
> > 
> > Brad
> > 
> > 
> > 
> > 
> > 
> > Chris McDonough <chrism@zope.com>
> > 04/15/2003 10:18 AM
> > 
> >         To:     Brad Powell/PPCO@Phillips
> >         cc:     zope@zope.org
> >         Subject:        Re: [Zope] Help with session data and redirects
> > 
> > 
> > Under Mozilla 1.3 on Linux, when running your test (e.g. when visiting
> > /createSessionAndRedirect?sessionText=456), I immediately get:
> > 
> > ## Page Template "view_session_obj.pt" ##
> > 
> > 456
> > 
> > Like you, I suspect this may be a browser issue. 
> > 
> > To verify, cause the createSessionAndRedirect to generate a "random"
> > query string like this:
> > 
> > session = context.REQUEST.SESSION
> > sessionObjName = 'redirectTest'
> > session.set(sessionObjName, sessionText)
> > return
> > 
> context.REQUEST.RESPONSE.redirect(context["view_session_obj.pt"].absolute_url() 
> 
> > + '?abc=%s' % context.ZopeTime().timeTime())
> > 
> > This should prevent browsers from returning a cached page.  A more
> > permanent solution would be to set a Pragma: No-Cache or Cache-Control:
> > No-Cache HTTP header within "view_session_obj.pt".
> > 
> > - C
> > 
> > 
> > On Tue, 2003-04-15 at 10:58, Brad Powell wrote:
> > > I have a problem where session data does not appear to be updated when 
> 
> > the 
> > > setting of the session data is followed by a response.redirect in a 
> > Python 
> > > script.  A browser refresh is required to get the correct data 
> > displayed. 
> > > This happens on both Zope v2.5.1 and v2.6.1.  It also happens with IE 
> > and 
> > > Mozilla browsers; but, interestingly, it does not occur with the 
> > Konqueror 
> > > browser.  This led me to believe it was a browser issue, but no matter 
> 
> > > what options I try in IE, I cannot get it to work.  I thought it might 
> 
> > be 
> > > an issue with the browser cache settings, but, again, no matter what I 
> 
> > try 
> > > I get the same result.
> > > 
> > > I've included a test script and page template that demonstrates this 
> > > problem. When I go to url "sessionCreateAndRedirect?sessionText=123", 
> I 
> > > get the message, "Problem: no session object (redirectTest)."  If I 
> then 
> > 
> > > refresh the browser, I get "123" displayed, which is the correct 
> > response. 
> > >  Subsequent calls to the url with different values for sessionText 
> > returns 
> > > the previous session value, until I do a browser refresh.
> > > 
> > > Any assistance, guidance, wisdom, etc. on this matter would be greatly 
> 
> > > appreciated.
> > > 
> > > 
> > > ## Script (Python) "sessionCreateAndRedirect"
> > > ##parameters=sessionText
> > > ##
> > > session = context.REQUEST.SESSION
> > > sessionObjName = 'redirectTest'
> > > session.set(sessionObjName, sessionText)
> > > return 
> > > 
> > 
> context.REQUEST.RESPONSE.redirect(context["view_session_obj.pt"].absolute_url())
> > > 
> > > ## Page Template "view_session_obj.pt"
> > > ##
> > > <html>
> > >   <head>
> > >     <title tal:content="template/title">The title</title>
> > >   </head>
> > >   <body>
> > >     <tal:block define="global sesObj request/SESSION/redirectTest | 
> > > nothing"></tal:block>
> > >     <p tal:condition="not:sesObj">Problem: no session object 
> > > (redirectTest).</p>
> > >     <p tal:condition="sesObj" tal:content="sesObj">session obj 
> > > contents</p>
> > >   </body>
> > > </html>
> > > 
> > > 
> > > Brad
> > 
> > 
> > 
> > 
> 
> 
> 
>