I agree, that the cookie is not set in a redirect, even if you include the <@userreferencecookie> tag. So I removed the <@userreferenceargument> in the redirects to get around this issue.
Although I do see that the <@userreferencecookie> is working as advertised, and so therefore this is not a bug, I did add a feature request that the <@userreferencecookie> will in the future write the cookie if the cookie does not exist, even if the search arg is present. I think if the cookie is not present, and there is a search arg user ref, then the cookie should be written with the valud of the search arg.
Is there a reason that I am not thinking of where the cookie should not be written if the cookie is not present? I cannot think of one.
Robert.
On Jan 20, 2004, at 10:33 PM, Robert Shubert wrote:
I don't believe that the redirect will ever set cookie because it would be unsure which domain to set it for. Redirects have the possibility, I'd dare say intention, to transverse domains, so you would only be setting a cookie at the domain you are leaving, and it wouldn't be useful. Why does the first hit get redirected? Is it to change 'domain.com' into 'www.domain.com'? Because that does constitute a domain change.
Glad you found it [and we're not all crazy :) ]
Robert
-----Original Message----- From: Robert Garcia [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 21, 2004 12:32 AM To: [EMAIL PROTECTED] Cc: Doug Platt Subject: Re: Witango-Talk: Cookie Bug
OK, I found the problem. I found why this is happening more for me and not for others, it has to do with redirecting.
On these apps there are several places where a first time hit gets redirected. On the first time hit, there is no search arg userref, but the cookie cannot be set, because it is a 302 redirect. Then, in my redirect, I attach the <@userreferenceargument> to the redirect location value, so on the next page the <@userreferencecookie> tag sees
the search arg and does not write the cookie. Then every subsequent page, has a <@userreferenceargument> attached in the url, so the cookie
is not written, then if there is url without the search arg, or manually put in, session state is lost, because there is no cookie.
The problem is there were bugs in the past, so I have gotten absolutely
religous with the <@userreferenceargument> and that is actually causing
a problem, not helping, now that the cookie bug seems to be fixed with 065.
I hope that makes sense. It seems the best thing to do is to go back to
the default header, and lose the <@userreferenceargument> at least in my redirects. It seems like there may be a case for not using the <@userreferenceargument> as a backup.
I will let you know how it works out. It would seem that the <@userreferencecookie> should write a cookie if it is not present, using the searcharg as the value if it is there, because unless I just don't know how to do it, you cannot use the <@userreferencecookie> tag in a 302 redirect.
I will have to change this from a bug to a feature request, and I now trying to figure if removing the <@userreferenceargument> from every redirect is going to cause me any problems anywhere.
Robert.
On Jan 20, 2004, at 9:09 PM, Robert Garcia wrote:
Yes, that is one of the ways I saw that the <@userreferencecookies> was not working properly.
I built a sniffer in RealBasic that performed http requests like a browser, and then looked at the value of the http Headers returned. Even if there was not search arg userref, there were times when the cookie was not attempted to be written. And my app, does not write cookies, so there is no way that the <@userreferencecookies> detected
a cookie. Once I did my work around, the set cookie header was present
every time, and my browser testing confirmed this. If I opened the browser preferences and watched my stored cookies, I could see when it
was created, and when it was not. With the default header, if I went to a witango page without a search arg, the cookie didn't create all the time, some times it did. Most of the time it did not. As soon as I
did the workaround, the cookie was created every time without fail._______________________________________________________________________
Robert.
P.S. I can send you an app that will hit a url and then show you the headers returned. It is a simple app that I wrote, it does the job.
On Jan 20, 2004, at 8:08 PM, Scott Cadillac wrote:
Have you tried an HTTP Sniffer yet?
--
Robert Garcia President - BigHead Technology VP Application Development - eventpix.com 5910 Clark Rd Suite G Paradise, Ca 95969 ph: 530.645.4040 x222 fax: 530.645.4040 [EMAIL PROTECTED] - [EMAIL PROTECTED] http://bighead.net/ - http://eventpix.com/ - http://theradmac.com/
_ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
--
Robert Garcia President - BigHead Technology VP Application Development - eventpix.com 5910 Clark Rd Suite G Paradise, Ca 95969 ph: 530.645.4040 x222 fax: 530.645.4040 [EMAIL PROTECTED] - [EMAIL PROTECTED] http://bighead.net/ - http://eventpix.com/ - http://theradmac.com/
_______________________________________________________________________ _
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
_______________________________________________________________________ _
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
--
Robert Garcia President - BigHead Technology VP Application Development - eventpix.com 5910 Clark Rd Suite G Paradise, Ca 95969 ph: 530.645.4040 x222 fax: 530.645.4040 [EMAIL PROTECTED] - [EMAIL PROTECTED] http://bighead.net/ - http://eventpix.com/ - http://theradmac.com/
________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
