Richard, Thanks for clearing that up. I figured the value was transformed by the parser, but I did not know that it could be urlencode. I will test it tomorrow and confirm that it is so, I tried to look in the manual but did not find it anywhere. Thanks a lot. MK --- Richard Lynch <ceo@xxxxxxxxx> wrote: > Pink Floyd wrote: > > (I had posted this in the Zend php-general mailing > > list > > but it did not show up in php.net, so here it is > > again) > > Greetings, > > I am not sure whether this is a bug or a 'feature' > > (new to PHP). I have a cookie that is set by our > > password server (NON-PHP) for our domain, whose > value > > is base64 encoded when set. > > Now, when I try to retrieve the Cookie from my > > PHP/Apache Web server the $_COOKIE['token'] value > is > > messed up. What I have noticed is the '+' > character is > > being replaced by ' '. > > I have the magic_quotes_gpc set to 'off' and > > variables_order set to 'gpcs' in my php.ini. > > Currently, I have hacked around by painfully > parsing > > the $_SERVER['HTTP_COOKIE'] variable and > extracting > > the 'token' cookie, where its value appears to be > > intact as set by our password server. > > > > I would like to avoid this hack if possible, is > there > > a way to retrieve the 'raw' cookie value without > php > > 'cleansing' it? > > There is a raw_headers variable, but it would be > even more to parse than > what you've got... > > It occurs to me, though, that PHP is almost for sure > using the same > under-lying code as http://php.net/urldecode and you > could just take the > cookie value you get and pass it through > http://php.net/urlencode to > "undo" the decode that PHP did. > > They're inverse functions, so it should be safe to > do that for any/all > munging that gets done, not just "+" <-> " " but > also any %XX that happens > to occur in your base64-encoded value. > > Still a "hack" but far less painful than parsing the > raw Cookie stuff > yourself, and you're less likely to screw up and > miss some kind of > "gotcha" with % or + or space or... > > If there *IS* a way to turn off PHP URL decoding, > it's gonna be in php.ini > and it's gonna be documented right in there. > > PHP doesn't have a bunch of undocumented "features" > that you rely on to > work. :-) > > PS It's a feature: > [Netscape Cookie spec excerpt] > "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." > > Since data often *DOES* have white space semi-colon > or comma (yours > doesn't, but that's the exception) then you have to > do SOME kind of > encoding on it. > > It's a lot easier to just always urlencode/urldecode > it than to document > and code every chunk of data that might or might not > have those > characters, and then only encode/decode the ones > that need it. > > base64 encoding is also a fine choice, of course, > but it's also easier to > handle untrusted data of Cookies, POST, and GET all > the same, and GET has > to be urlencoded, so urlencoding is the choice made. > > So you basically want to do: > $token = > base64_decode(urlencode($_COOKIES['token'])); > and Bob's your uncle. > > -- > Like Music? > http://l-i-e.com/artists.htm > > __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
