--- Steve Buehler <[EMAIL PROTECTED]> wrote:
> hmmmm. This seemed to set the cookie just fine.
I thought it might. :-)
> Does this mean that either localhost in the browser or
> Apache/PHP on a windows box has to set the cookie differently
> than on RedHat/Apache/PHP?
Nope, it just means that the hostname you were assigning to the cookie was
wrong from the browser's perspective. You see, the cookie probably was in
fact getting set by the browser, but it did not send it back to the server
on the next request, because it didn't think the hostname matched the
server it was connecting to.
Basically, a cookie consists of a name and value only. Everything else
places an access restriction of some sort on the cookie. Some
restrictions, such as hostname and expiration, have defaults that are
assigned if you do not specify. The default expiration date is at the end
of the browser session, and the default hostname is the current hostname.
So, by leaving out hostname, you're sure to get it right, because it's
whatever the browser thinks the current host is.
> Basically, by this test, it sounds like on my laptop I have to
> use a header('Set-Cookie: ...); instead of
> setcookie ("coach_access[login_id]", "coach",0,"/","$cookhost");
No, both functions essentially do the same thing - add a Set-Cookie header
to the response headers you are sending. The setcookie() is just sort of a
more friendly method than setting the header yourself. I prefer header(),
but you can use setcookie(). If you will read
http://www.php.net/setcookie, you will see that most of the parameters are
optional.
> On another note, why would this work on the RedHat, but not
> the WinXP Apache/PHP?
I'd say it's only a hostname mismatch and has nothing to do with anything
else.
Hope that helps.
Chris
=====
Become a better Web developer with the HTTP Developer's Handbook
http://httphandbook.org/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
