Jon Anderson writes:
> Cookies must be encoded somehow: Because a raw cookie will contain
> "var=val; expires=time; path=/path/" type stuff, PHP would *have* to
> encode it.
I don't mean to be thick, Jon, but I don't understand why it has to be
encoded at all. Are you saying that the "path=/path/" has to be encoded?
Well, ok (I don't entirely understand that either), but why encode
the "val"? "val" can be arbitrary data and shoud be left uninterpreted,
in my opinion.
> If a user runs "setcookie('mycookie','this is my cookie; have
> a bite!');", PHP has to pick some kind of encoding, and urlencoding
> makes the most sense given its similarities to GET and POST.
Yes, it does seem like PHP does this because it wants to treat cookies
similarly to GET and POST urls. But cookies are intrinsically different,
it seems to me. In particular, they are not urls.
> Since PHP urlencodes values it sets, it follows logically that it would
> also urldecode values it retrieves.
But there many other applications which are not written in PHP, nor is
there a standard which specifies url encoding for cookies as far as I know
(if there is, then all bets are off--I'm wrong, and I will go away :)).
Shouldn't PHP be designed to interoperate with these applications?
> If you don't want PHP's automagic cookie handling you can do it manually
> as well with header('Set-Cookie: ...') and $_SERVER['HTTP_COOKIE'] on
> the other end - which I believe is what you decided on.
Yep. But is this fact documented somewhere? I missed it.
Fletcher
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
