I'm sure this is not the right way <grin>, but I had this problem a while
ago, and ended up manually setting the domain of the cookie to null/undef.
I use cgi.pm to set the cookie, as follows. Note that where $q is a CGI.pm object
reference.
This is code extracted from an app framework running under registry,
so it is not complete nor correct by any means, but should give an
idea of the approach ...
my $cookies = [ $q->cookie(-name=>'CookieName',-value=>'CookieValue',-path=>'/') ];
$cookies->[0]->{domain} = undef;
and then later on ....
print $self->cgi->header(-cookie=>$cookies,-type=>"text/html; charset=iso-8859-1");
I seems that CGI.pm->cookie() method was, at least for me at the time,
forcing/defaulting the domain name of the cookie to be that of the
server. When I set it to undef, it the browser then associated it
with the current server, which was the proxy.
Of course, I might be dead wrong about the why, but I know it works for me. I have
my mod_perl server running on a high port (bound to localhost), and my stronghold
proxy on
port 80 (bound to the published IP), which is similar to the described
configuration.
Of course, this is probably not the "right" way, but it worked/works
for me (until someone suggests a better one ...)
Brgds,
Mike.
