This is a pretty basic issue, having to do with HTTP headers. The reason I'm converting, is that it took witango would not run on my deployment platform (Redhat 9) until last week, and I HAD to build something, somewhere in order to eat. I fully expect to have to go through my apps carefully (scopes and quotes are on my list). But, independent of converting, I just want my cookies sent in the HTTP header.
The basic problem is <@SETCOOKIES> does NOT result in cookies being included in the header. Whether this worked in 3.52, or any other app server is irrelevant. It needs to work in witango5 on redhat linux and apache2 in order for me to keep eating. One comment in this thread concerned whether cookies can be set in a 302 redirect. They can, and the USERREFERENCECOOKIE demonstrates that witango can do this. So this means there is nothing in the way witango is interacting with my apache2 build to prevent cookies from working (eg. the as-is module). To understand what was happening, I assigned the header both to request$httpHeader and user$httpheader1. The debug output on the re-directed page showed that my cookies were getting assigned to user$httpheader1 but not to request$httpHeader. I commented that I was surprised that USERREFERENCECOOKIE was not assigned to user$httpheader1, but was assigned to request$httpHeader. I think this started the issue of what changed. Again, I don't care what changed, as long as it works. Hearing about changes in header handling makes me concerned that there will be some interaction between <@SETCOOKIES> and <@USERREFERENCECOOKIE> that could come into play. I have not yet, but will do a thorough test today to understand the interactions between to try to understand what is happening to the HTTP header. If I can't figure out how to make <@SETCOOKIES> work, I'm hoping a work-around will be to explicitly write my cookies into the HTTP header, instead of using the <@SETCOOKIES> tag. >No, nope, no way, uh uh, wasn't me, I had nothing to do with this >change. I'll deny everything! <@GRIN> > >If you are asking if I can shed some light on this, I have to agree >with what was said in another post. Much has changed since 3.5x was >originally released. For me to be able to list everything would be next >to impossible, at times I have problems remembering what I did this >morning! Seriously, sometimes I have to stop and think "was that a >Tango 1.x, 2.x, 3.x, 2000, SPx, FTF, or Witango 5 change or new >feature" if someone asks a question about a configuration that isn't >recent. > >During Witango/Tango's history, there have been changes to the default >settings for userKey, there have been changes to how >userreferenceargument is created, there have been different ways of >creating items (including cookies) with regards to the use of Carriage >Returns and Line Feeds. Some of which were platform specific. > >Bill, It's great to see you move up to Witango, but you have to >understand that you are coming from a world that most of us have not >had to deal with for 4 years, since Tango 2000 was released. I'm going >to suggest a different approach. Instead of trying to 'convert' >something, perhaps it would be easier to create a new test example, >find out how to do whatever it is that you are trying to do, then when >you've got it working apply the logic to the files that you are trying >to convert. Perhaps someone has an example that they've created using >only Witango or Tango 2000 that they could share. I'm sure that it >would be much easier for others on the list to help you to get >something new to work, rather than to help you convert from something >that they may never have used. > >I understand your frustration, I'm just completing my OS 9.x to OS X >conversion and I can't tell you how many times I've used the "...but it >worked that way in OS 9!" > >Just my 2 cents (Cdn. which at the current rates of exchange, is much >closer to being 2 cents than it has been in a long time). > >Steve Smith > >Oakbridge Information Solutions >Office: (519) 624-4388 >GTA: (416) 606-3885 >Fax: (519) 624-3353 >Cell: (416) 606-3885 >Email: [EMAIL PROTECTED] >Web: http://www.oakbridge.ca > >On Wednesday, June 11, 2003, at 06:58 AM, Simon Boddy wrote: > >> Hi Bill, list, >> >> There is certainly no problem with setting cookies and redirecting in >> the same HTTP response. After a spate of embarrassing session hijacks, >> we now only set the session cookie on redirect, because it seems to be >> the only way to ensure the page setting the cookie is not cached by >> proxies. It's interesting for me to discover that this was default >> behaviour in 3.5. Why was it changed I wonder? Steve Smith? >> >> If your cookies are not setting, my hunch would be to take out some >> carriage returns. <@userreferencecookie> and <@setcookies> both >> include a terminating carriage return. Empty lines in HTTP headers is >> asking for trouble. >> >> Another thing to beware is that IE6 will dump without warning all >> cookies from servers referenced by network name if that name contains >> an underscore. M$ claim this is by design. We have one guy in >> psychiatric ward after weeks of effort to find that one! >> >> Good Luck. >> Simon >> >> >> -----Original Message----- >> From: Witango Customer Support [mailto:[EMAIL PROTECTED] >> Sent: 11 June 2003 03:30 >> To: [EMAIL PROTECTED] >> Subject: Re: Witango-Talk: <@SETCOOKIES> >> >> >> Bill, >> I am not sure that cookies will be set with a 302 status. Try sending >> the >> user reference argument in the location field. The server would then >> reconnect to the same session. >> >> Try outputting the results instead of setting the header and see what >> the >> string being is generated looks like. >> >> We see the following: >> >> <@ASSIGN cookie$abc "ABC"> >> <@ASSIGN cookie$123 "123"> >> <@ASSIGN cookie$XYZ "xyz"> >> <@PURGERESULTS> >> <@ASSIGN NAME="httpHeader1" SCOPE="request" VALUE="HTTP/1.1 302 >> <@crlf>Location: /<@VAR >> name="good_login_return" scope="user" >> encoding="none"><@crlf><@SETCOOKIES><@crlf><@USERREFERENCECOOKIE><@crlf >> ><@cr >> lf>"> >> @@request$httpHeader1 >> >> Produces this >> >> HTTP/1.1 302 Location: / Set-cookie: XYZ=xyz; path=/; Set-cookie: >> 123=123; >> path=/; Set-cookie: abc=ABC; path=/; >> >> >> <@USERREFERENCECOOKIE> does not produce anything as the cookie has >> already >> been set. >> >> >> >> Witango Support >> >> >> >> On 11/6/03 1:00 AM, "Bill Conlon" <[EMAIL PROTECTED]> wrote: >> >>> Thx, >>> >>> I did indeed have the wrong scope in the results action, but I >>> retested >>> with request scope without success using the following. >>> >>> <@PURGERESULTS> >>> <@ASSIGN NAME="httpHeader" SCOPE="request" VALUE="HTTP/1.1 302 >>> <@crlf>Location: <@VAR >>> name="good_login_return" scope="user" >>> encoding="none"><@crlf><@SETCOOKIES><@USERREFERENCECOOKIE><@crlf><@crl >>> f>"> >>> >>> This is consistent with behaviour using the ASSIGN action (where I did >>> have the httpHeader variable scoped as Request). >>> >>>> Bill, >>>> Try using request scope for httpHeader. HttpHeader probably will >>>> not work >>>> in cookie scope. >>>> >>>> <@PURGERESULTS> >>>> <@ASSIGN NAME="httpHeader" SCOPE="cookie" VALUE="HTTP/1.1 >>>> 302<@crlf>Location: <@VAR name="good_login_return" scope="user" >>>> encoding="none"><@crlf><@SETCOOKIES><@crlf><@USERREFERENCECOOKIE><@cr >>>> lf><@cr >>>> lf>"> >>>> >>>> >>>> Witango Support >>>> >>>> >>>> On 10/6/03 12:02 PM, "Bill Conlon" <[EMAIL PROTECTED]> wrote: >>>> >>>>> Yep. Looks like a bug. >>>>> >>>>> If I do the same assignment to a user scope variable, I see the >>>>> header >>>>> value I want in the debug output on the re-directed page. But the >>>>> cookie >>>>> itself is not delivered to the browser. >>>>> >>>>> Als curious; the USERREFERENCE cookie does not get included in my >>>>> user >>>>> variable, but appears to over-write my assigned cookies in the >>>>> actual >>>>> httpHeader. >>>>> >>>>> I've filed a bug report. >>>>> >>>>> Have you tried reading the contents of the variable to make sure >>>>> that >>>>> that it contains what you are expecting? Two things that you can >>>>> look >>>>> at that are new in Witango 5: >>>>> >>>>> There have been changes with regards to the way Witango 5 resolves >>>>> paths. >>>>> >>>>> Also from the What's New in Witango 5: >>>>> >>>>> The httpheader config variable does not function the same way as >>>>> Tango >>>>> 2000. You will now need to send complete http headers, not >>>>> partial >>>>> header like Tango 2000 allowed. There are 2 new tags to assist >>>>> you in >>>>> formulating http headers - @HTTPREASONPHRASE and @HTTPRESPONSECODE >>>>> >>>>> Hope this helps, >>>>> >>>>> Steve Smith >>>>> >>>>> Oakbridge Information Solutions >>>>> Office: (519) 624-4388 >>>>> GTA: (416) 606-3885 >>>>> Fax: (519) 624-3353 >>>>> Cell: (416) 606-3885 >>>>> Email: [EMAIL PROTECTED] >>>>> Web: http://www.oakbridge.ca >>>>> >>>>> On Monday, June 9, 2003, at 08:58 PM, Bill Conlon wrote: >>>>> >>>>> Redhat 9/Apache2/Witango 5.01.059 >>>>> >>>>> Here's my custom header: >>>>> >>>>> <@PURGERESULTS> >>>>> <@ASSIGN NAME="httpHeader" SCOPE="cookie" VALUE="HTTP/1.1 302 >>>>> <@crlf>Location: <@VAR >>>>> name="good_login_return" scope="user" >>>>> encoding="none"><@crlf><@SETCOOKIES><@crlf><@USERREFERENCECOOKIE>< >>>>> @crlf >>>>> <@c >>>>> rlf>"> >>>>> >>>>> This redirects to the appropriate page (specified by the variable >>>>> good_login_return, and includes a USERREFERNCECOOKIE, but other >>>>> cookies >>>>> are not set in the http header. >>>>> >>>>> This works in 3.52. Can anyone see an error. I'm afraid I've >>>>> been >>>>> staring at it too long. >>>>> >>>>> thx. >>>>> >>>>> Bill Conlon >>>>> >>>>> To the Point >>>>> 345 California Avenue Suite 2 >>>>> Palo Alto, CA 94306 >>>>> >>>>> office: 650.327.2175 >>>>> fax: 650.329.8335 >>>>> mobile: 650.906.9929 >>>>> e-mail: mailto:[EMAIL PROTECTED] >>>>> web: http://www.tothept.com >>>>> >>>>> >>>>> __________________________________________________________________ >>>>> _____ >>>>> _ >>>>> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf >>>>> >>>>> >>>>> >>>>> ___________________________________________________________________ >>>>> _____ >>>>> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf >>>>> >>>>> >>>>> Bill Conlon >>>>> >>>>> To the Point >>>>> 345 California Avenue Suite 2 >>>>> Palo Alto, CA 94306 >>>>> >>>>> office: 650.327.2175 >>>>> fax: 650.329.8335 >>>>> mobile: 650.906.9929 >>>>> e-mail: mailto:[EMAIL PROTECTED] >>>>> web: http://www.tothept.com >>>>> >>>>> >>>>> ____________________________________________________________________ >>>>> ____ >>>>> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf >>>> >>>> _____________________________________________________________________ >>>> ___ >>>> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf >>>> >>> >>> >>> Bill Conlon >>> >>> To the Point >>> 345 California Avenue Suite 2 >>> Palo Alto, CA 94306 >>> >>> office: 650.327.2175 >>> fax: 650.329.8335 >>> mobile: 650.906.9929 >>> e-mail: mailto:[EMAIL PROTECTED] >>> web: http://www.tothept.com >>> >>> >>> ______________________________________________________________________ >>> __ >>> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf >> >> _______________________________________________________________________ >> _ >> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf >> >> >> ******************************************************************** >> This message is intended only for the use of the person(s) ("the >> intended >> recipient(s)") to whom it is addressed. It may contain information >> which is >> privileged and confidential within the meaning of applicable law. If >> you >> are not the intended recipient, please contact the sender as soon as >> possible. The views expressed in this communication may not necessarily >> be the views held by LGCSB (Local Government Computer Services Board). >> >> Any attachments have been checked by a virus scanner and appear to be >> clean. >> Please ensure that you also scan all messages, as LGCSB does not accept >> any liability for contamination or damage to your systems. >> ******************************************************************** >> >> _______________________________________________________________________ >> _ >> TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf >> >> >Steve Smith > >Oakbridge Information Solutions >Office: (519) 624-4388 >GTA: (416) 606-3885 >Fax: (519) 624-3353 >Cell: (416) 606-3885 >Email: [EMAIL PROTECTED] >Web: http://www.oakbridge.ca > > >________________________________________________________________________ >TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf Bill Conlon To the Point 345 California Avenue Suite 2 Palo Alto, CA 94306 office: 650.327.2175 fax: 650.329.8335 mobile: 650.906.9929 e-mail: mailto:[EMAIL PROTECTED] web: http://www.tothept.com ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
