On Fri, 2007-02-09 at 20:38 -0600, Fletcher Mattox wrote: > Robert Cummings writes: > > > Dear numnutz, get off your lazy arse and read the doc for yourself: > > > > http://wp.netscape.com/newsref/std/cookie_spec.html > > > > It clearly states: > > > > NAME=VALUE > > This string is a sequence of characters excluding semi-colon, comma and > > white space. If there is a need to place such data in the name or value, > > some encoding method such as URL style %XX encoding is recommended, > > though no encoding is defined or required. > > > > There, it left the encoding up to whoever is decoding it. Now feel free > > to take your troll ass and hide under a bridge someplace. > > Actually, wouldn't you say it is left up to whoever is sending the cookie? > But more on that later. > > Here is my point of view, if you are interested. When the specification > for a language reads "encoding is recommended, but not required", then > it is leaving the decision to encode or not to encode up to the sender. > The sender is in the driver's seat and the receiver must follow suite. But isn't the sender and receiver usually one and the same. I mean your PHP application is usually what set the cookie in the first place. Then you receive it in the very same PHP application. I realize that the cookie is technically sent by the browser, but the browser doesn't process cookies other than to store them. It's akin to sending a message into the future to yourself in some encoded format. You are both the sender and receiver and so one would expect you can decipher your own message. > (Side note: this is an inherently BAD specification since it requires > out-of-band agreement between the sender and receiver, and this is what > puts the developers of PHP in such a tough position.) The receiver must > be able to handle either case. But PHP does not permit this. Instead, > PHP, in an attempt to avoid the chaos inherent a bad spec, has made the > decision for the sender. Well PHP made the decision with the greatest flexibility. It chose to encode the cookie in such a way as to allow developers to include special characters in the cookie value. > The sender must encode, and has no choice. > I think this is at the root of my frustration. I want control. :) You have control over the value you insert into the cookie. If you find the encoding problematic, you have the control to encode it first in base64 (as this message happens to be titled). So where exactly do you see loss of control? > Also, keep in mind that in my case the sender is a third party over > whom I have no control. Given a spec like this, I prefer cooperation > between sender and receiver rather than a decision by fiat made by the > programming language. Ah, so you have a mixed language environment. Well you can use the header() function to send the cookie header yourself. This allows you control over the sending. You can also use apache_request_headers() to get full control over the incoming request headers. > > Now that I have seen the spec (thank you!), I can at least understand > why the PHP developers made the decision they did. I still disagree > with it, but I was seeking only an understanding, and I have found that. > I hope you will agree I was not trolling here. Yep. > Oh. One more thought. If you wish to argue that PHP does provide > for both cases with $_COOKIE and $_SERVER['HTTP_COOKIE'], then I will I'm not aware of a $_SERVER['HTTP_COOKIE'] field. Perhaps you meant $GLOBALS['HTTP_COOKIE_VARS']? If so, it is identical to $_COOKIE with $GLOBALS['HTTP_COOKIE_VARS'] being deprecated. > grudgingly agree with you. See we can agree. :) In that case, all I ask > is for a little documentation. Is the distinction in these two variables > documented somewhere? I have looked and looked and have come up empty. > I am asking this question with humility and sincerity. I am asking it > because I honestly wish to learn. I think you have misjudged my motives > and my character. http://www.php.net/manual/en/function.header.php http://www.php.net/manual/en/function.apache-response-headers.php Hope that helps. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
