# behavior of translating dot in the query variable name into underscore character - Thread: https://externals.io/message/54519 - Original archive: https://news-web.php.net/php.internals/54519 - Started by Laruence on 2011-08-12T10:31:33+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #54519 — Laruence — 2011-08-12T10:31:33+00:00 URL: https://externals.io/message/54519#54519 Hi: a request uri : http://***/a.b=2 will result $_GET["a_b"] = 2 ( the dot was translated into underscore char); my point is , since register_globals has be removed already( in my opinion this behavior only make sence when register_globals on), should we remove this translating behavior too? thanks -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #54522 — Etienne Kneuss — 2011-08-12T10:42:27+00:00 URL: https://externals.io/message/54519#54522 · In reply to: #54519 Hello, > Hi: >     a request uri : http://***/a.b=2  will result $_GET["a_b"] = 2 ( > the dot was translated into underscore char); > >     my point is , since register_globals has be removed already( in > my opinion this behavior only make sence when register_globals on), > should we remove this translating behavior too? For BC reasons there is no way we can simply remove it. Old code might rely on it without relying on register_globals. Best, > > thanks > > -- > Laruence  Xinchen Hui > http://www.laruence.com/ > > -- > > > > -- Etienne Kneuss http://www.colder.ch --- ## #54526 — Kalle Sommer Nielsen — 2011-08-12T11:23:04+00:00 URL: https://externals.io/message/54519#54526 · In reply to: #54522 Hi Etienne 2011/8/12 Etienne Kneuss > For BC reasons there is no way we can simply remove it. Old code might > rely on it without relying on register_globals. Although we could assign both, but I guess that would eat more memory that it might actually benefit. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #54535 — Mats Lindh — 2011-08-12T13:12:34+00:00 URL: https://externals.io/message/54519#54535 · In reply to: #54526 > > […] > Although we could assign both, but I guess that would eat more memory > that it might actually benefit. Would it be possible to assign it as a reference and change the reference on the first write (similar to copy-on-write)? In that case I'd suggest doing something similar to: * Assign all variables to their provided name * Assign a reference as the "cleaned" version of their name if there isn't already an existing version of the clean name in the map Quite a few services use "." in their query string variables (such as Solr, for one), and the mangling of the query string names requires you to parse the query string yourself if you want to write a front end service accepting the same kind of API. -- Mats Lindh --- ## #54536 — Derick Rethans — 2011-08-12T13:20:08+00:00 URL: https://externals.io/message/54519#54536 · In reply to: #54519 > a request uri : http://***/a.b=2 will result $_GET["a_b"] = 2 ( > the dot was translated into underscore char); > > my point is , since register_globals has be removed already( in > my opinion this behavior only make sence when register_globals on), > should we remove this translating behavior too? No. No reason to change anything that isn't broken. Chanhing this will mean a BC break, even for people that don't use register_globals. Derick --- ## #54538 — Ferenc Kovacs — 2011-08-12T13:48:18+00:00 URL: https://externals.io/message/54519#54538 · In reply to: #54536 > > > > […] > > No. No reason to change anything that isn't broken. Chanhing this will > mean a BC break, even for people that don't use register_globals. > it is broken, we just sucked it up. if we would both provide the foo_bar and foo.bar: - if your code expects foo.bar to be foo_bar, it's there. - if you expect foo.bar, it's also fine. - if you did a workaround in the past (parse the query string manually), that would also work, in the worst case, you would overwrite the foo.bar with the same value. so it's not much userland BC (not until we remove the foo_bar syntax), except maybe if you do some really strict input validation (abort if there is an request variable not specified in the whitelist). I don't mind if this only ships with the next minor or major version, but it would be really awkward keeping this workaround much longer for a design problem which isn't there anymore. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #54540 — Laruence — 2011-08-12T14:12:09+00:00 URL: https://externals.io/message/54519#54540 · In reply to: #54538 Hi: I am goot at debate as my poor english, I try to make my point clearly, that is , I think there is one reason to do this change, that is "what you saw should be what you get", this behavior confused any pepole who meet this issue first, and need explained by document, I agree with Tyral:"it would be really awkward keeping this workaround much longer for a design problem which isn't there anymore." thanks 2011/8/12 Ferenc Kovacs : > > > […] > > it is broken, we just sucked it up. > if we would both provide the foo_bar and foo.bar: > > - if your code expects foo.bar to be foo_bar, it's there. > - if you expect foo.bar, it's also fine. > - if you did a workaround in the past (parse the query string > manually), that would also work, in the worst case, you would > overwrite the foo.bar with the same value. > > so it's not much userland BC (not until we remove the foo_bar syntax), > except maybe if you do some really strict input validation (abort if > there is an request variable not specified in the whitelist). > I don't mind if this only ships with the next minor or major version, > but it would be really awkward keeping this workaround much longer for > a design problem which isn't there anymore. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #54541 — Laruence — 2011-08-12T14:12:57+00:00 URL: https://externals.io/message/54519#54541 · In reply to: #54540 s/goot at/not good at/ sorry 2011/8/12 Laruence : > Hi: >  I am goot at debate as my poor english, >  I try to make my point clearly, > >  that is , I think there is one reason to do this change, that is > "what you saw should be what you get", > >  this behavior confused any pepole who meet this issue first, and > need explained by document, > >  I agree with Tyral:"it would be really awkward keeping this > workaround much longer for  a design problem which isn't there > anymore." > > thanks > > 2011/8/12 Ferenc Kovacs : > > […] > > > > -- > Laruence  Xinchen Hui > http://www.laruence.com/ > -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #54542 — johannes@schlueters.de — 2011-08-12T14:31:13+00:00 URL: https://externals.io/message/54519#54542 · In reply to: #54538 Hi, > if we would both provide the foo_bar and foo.bar: > > - if your code expects foo.bar to be foo_bar, it's there. > - if you expect foo.bar, it's also fine. > - if you did a workaround in the past (parse the query string > manually), that would also work, in the worst case, you would > overwrite the foo.bar with the same value. ... and we make it complicated for everybody iterating over the array to do some work on all elements. johannes --- ## #54543 — Ferenc Kovacs — 2011-08-12T15:26:16+00:00 URL: https://externals.io/message/54519#54543 · In reply to: #54542 2011/8/12 Johannes Schlüter : > Hi, > > > > […] > > ... and we make it complicated for everybody iterating over the array to > do some work on all elements. > please explain! your foreach would work exactly in the same way. your logic would only break, if you blow up on unexpected request variables, which is much less frequent usecase imo. (as I mentioned maybe for some really strict request validation) -- Ferenc Kovács @Tyr43l - http://tyrael.hu