On Sun, 27 Feb 2005 19:11:03 -0800, Joshua Chamas <[EMAIL PROTECTED]> wrote:
> Skylos wrote:
> > ...
> > $Response->Cookies('ccc', 'key', 'val') ;
> > $Response->Cookies('ccc', 'Domain', 'mydomain.com');
> >
> > resulted in
> >
> > $Response->{Cookies}{ccc}{key} = 'val';
> > $Response->{Cookies}{ccc}{Domain} = 'mydomain.com';
> >
>
> This should work fine. The function AddCookieHeaders() should
> pick up this data correctly and do the right thing.
Ahh, this is the part I couldn't figure from looking at the code.
> > when it should have resulted in
> >
> > $Response->{Cookies}{ccc}{Value}{key} = 'val';
> > $Response->{Cookies}{ccc}{Domain} = 'mydomain.com';
>
> Using Value is one way it could be represented internally.
>
> > Did I miss a fix thats already been submitted? Is a fix needed to be
> > submitted to correct this problem? Am I using the method incorrectly?
>
> What is the bug exactly, that this code did not work for you?
>
> $Response->{Cookies}{ccc}{key} = 'val';
> $Response->{Cookies}{ccc}{Domain} = 'mydomain.com';
Ack, I didn't explain it right. No... its that this...
$Response->Cookies("ccc", "refReferer", $ENV{HTTP_REFERER});
$Response->Cookies("ccc", "Domain", "colorclimax.com");
$Response->Cookies("ccc", "refCode", "d10200");
did not result in what I want - things would happen like, the
refReferer would be there, but the refCode would not be - or vice
versa if I changed the order. And sometimes the cookie wouldn't seem
to get set at all.
But after alot of struggle, I managed to extract the form of the hash
from the code analysis, and found that if I set it up using the hash
notation,it worked as I needed it to. This makes me think that
there's something funky goin on in that code, that there's a bug in
there somewhere...
I assume this function, AddCookieHeader or whatever it is - actually
has a list of 'special' key attributes, 'Domain', 'Path', 'Expires',
etc?
I also have a suspicion that it may be related to urlencoding - some
older browsers like safari don't handle non-urlencoded cookies very
well (I fought with this compatibility issue on another project)
getting confused about the multiple = signs in there, apparently. I
had to urlencode my cookie strings. So they looked more like this:
Set-Cookie: ccc=refCode%XXd10200%XXrefReferer%XX;
Domain=colorclimax.com; Path=/;
> Note, you should use either the hash method directly, or the API call,
> but not both. You might be tripping up something odd if you are switching
> your method of access.
I want to use the API call. This is how its 'supposed to be' in my
head. I'm using the ASP object model, I should not depend on internal
structures of objects.
> > I worked around it by populating the Response->{Cookies} hash manually for
> > now.
>
> That is a fine way to go.
Its counter to my philosophy though. :P
> > Now the REAL perplexing problem.
This problem seems to have evaporated. They went to the non-sticky
configuration again (without telling me), and everything is working...
Gah, I hate it when there was a problem and I couldn't figure it. But
anyway...
> 2 things come to mind ...
>
> 1) if there is $Session data that is relevant to the user, and that is
> being stored on the local file system, then switching to another system
> will not work, you'll need sticky sessions
Sessions are turned off and not used. Multi-server setup makes them useless.
> 2) if the load balancers are actually redirecting to a web server with a
> new domain, then it may be that the browser is not sending the cookie
> to the new server despite your Domain flag set above, and you might
> this test.
Both web servers have the exact same configuration. - the config files
are rsynced between them.
Skylos
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
