Posted by Pink Floyd on 03/09/05 04:37

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@l-i-e.com> 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/

[Back to original message]