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
