On Sat, 2007-02-10 at 17:01 -0600, Fletcher Mattox wrote: > Robert Cummings writes: > > > 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. > > No! Not in this case. The first sentence in my original message was: > > "A campus web server (not under my control) returns an > authentication string in a cookie named AUTH." > > Rob, is this why you are giving me such a hard time? Do you think I > wrote the code which set the cookie? No, I missed that part and came in when you were complaining that nobody could give you a reason why PHP does what it does. Then when I gave you a reason, you complained that nobody had yet given you a link to a reference doc yet. It hink the use of "giving" you a hard time is incorrect. A more apt word would "gave", and even then I was still providing you with information. > The application which originated the cookie runs on a computer across > campus, and was written by our ITS department. I work in the CS > department. I have no access to that application. I don't even know > which language it is written in. Given this information, would you be > comfortable asking ITS to change their code just to make my application > happy? I wouldn't. No, as you should have noted later in the email I realized that you are working with a heterogeneous system. Do you respond to an email on first pass? I always read first then respond after I've read the entire post. > > > 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. > > As I keep trying to say, I am not sending the cookie. I do not have > that option. As I said, I missed the beginning of the thread, and when I came into thread it didn't seem an issue since you were focused on why the encoding was the way it was. > > This allows you > > control over the sending. You can also use apache_request_headers() to > > get full control over the incoming request headers. > > Ah. Interesting. I was not aware of that function. Thanks. > > > > 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. > > $_SERVER fields are dependent on your http server. My server (apache) > provides HTTP_COOKIE. Perhaps yours does not? I use Apache also. I have no idea what it does, never needed it. But since it's provided by Apache, it seems the Apache docs are where you should look. > > > 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 > > Thanks for the pointers, but my request is for documentation of the fact > that $COOKIE has been urldecoded(). Do you know where that documentation > lives? You seem to b lost in confusion. I don't have the documentation you want, instead I provided you with links to functions that allow you the control you so vehemently argue PHP has taken away from you. > Say, I just noticed RFC 2965. It essentially agrees with the Netscape > document on this matter, but it words it a little more clearly: > > The VALUE is opaque to the user agent and may be anything the > origin server chooses to send, possibly in a server-selected > printable ASCII encoding. > > The server is in control. The encoding, if any, is decided by the server. > No question about it. In my case, the server decided not to encode. > > In my opinion, PHP has done me a disservice by "decoding" (corrupting) > that value, putting it in the $_COOKIE variable and then not clearly > documenting it. PHP has done no such thing. PHP still allows you raw access to headers and received headers. It's up to you to you to get down and dirty and use the resources that cut closer to the grain. > Does anyone else see my point here, or am I way off base here? You're somewhat in lala land. I don't mean this as an insult, just an observation. You seem so locked onto arguing the point that you've failed to see in the last email I sent that I provided you with links to the tools you need to get at what you say you can get at *sheesh*. 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
