behavior of translating dot in the query variable name into underscore character

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.

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

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 tyra3l@gmail.com:

     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.

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/

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