PHP 4.0 Bug #6685 Updated: %20 mis-converted in GET mechanism

ID: 6685 Updated by: sniper Reported By: waldschrott@php.net Status: Analyzed Bug Type: *General Issues Assigned To: Comments: I think that having spaces in variable names is not a good thing (tm). could someone please explain me how it would be useful at all? --Jani Previous Comments: --------------------------------------------------------------------------- [2000-09-16 17:59:27] stas@php.net On the second though, you _can_ have variables with spaces (actually, you can name variable with every string you can put into variable), so I don't quite understand the maning of that variable name translation. Do we really need it? Anybody will have problems if we remove it? --------------------------------------------------------------------------- [2000-09-12 13:46:32] waldschrott@php.net since we all (almost) agree that register_globals should be deprecated ASAP and array indices with spaces are legal and URIs containg QUERYSTRING with them too, well at least the $HTTP_GET_VARS array should contain the non-converted information, if register_globals=on this mechanism can be applied for global variables We shouldn´t obscure URI data. --------------------------------------------------------------------------- [2000-09-12 13:41:29] stas@php.net And what would you expect it to do? You cannot have variable names with spaces. --------------------------------------------------------------------------- [2000-09-12 13:39:37] waldschrott@php.net I guess this is has the potential to be a serious bug since I think I´m allowed to take any key/value pairs I want to if encoded correctly, very simple to reproduce Call a page with this QueryString ?%20asd%20%20=%20asdf (you can replace %20 with + if you want to, same effect) and look what happened to to the key part of key=value <?php var_dump($HTTP_GET_VARS); ?> all leading spaces are stripped, all trailing ones converted to "_" - that really does not make sense, I don´t know what else is converted with mystic rules, I found these The only workaround is to access the QueryString directly which seems to be fine (of course) --------------------------------------------------------------------------- Full Bug description available at: http://bugs.php.net/?id=6685