Bill,
There have been many changes in functionality since 1998 (I think) when
Tango 3.5 was released so it is hard to compare what Tango 3.5 does to the
current version 5 years later.

User reference cookies in T2K and W5 are now only set if they are absent
from the request that was received by the server.  If the userreference
cookie value is present the cookie is not set again in the response so
<@USERREFERENCECOOKIE> returns an empty string.  This is documented in both
the T2K meta tags guide and the Witango 5 Programmers Reference.  So
@userreferencecookie is operating as documented.

If you want to explicitly set the user reference on every response from the
server you will have to code it.

E.g.

"HTTP/1.0 302<@CRLF>Location: <@VAR name=good_login_return scope=user
encoding=none><@CRLF><@SETCOOKIES><@CRLF>Set-cookie:
<@USERREFERENCE><@CRLF><@CRLF>"



Witango Support

On 11/6/03 3:12 PM, "Bill Conlon" <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> Cookies were set in Tango 3.52 using a 302 re-direct.  Here's the
> assignment to local$httpheader from the same file originally created and
> tested in 3.52 (using AppleShareIP not Apache):
> 
> "HTTP/1.0 302<@CRLF>Location: <@VAR
> name=good_login_return scope=user
> encoding=none><@CRLF><@SETCOOKIES><@USERREFERENCECOOKIE><@CRLF><@CRLF>"
> 
> So I don't think there is anything per se that prevents assigning cookies
> in a 302 redirect.  In fact I have cleared the user reference cookie, and
> then verified that it gets reset during the redirect.   So I'm pretty
> sure this is a bug.
> 
> As mentioned earlier in this thread, I did assign the same value to a
> user variable, which is output semi-appropriately in the redirected page.
> 
> I say semi, because my cookies are included, but the userreference cookie
> is not.
> 
> 
>> 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><@crlf>">
>>> 
>>> 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><@crlf><@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
>> 
> 
> 
> 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

Reply via email to