Dots and spaces in variable names are converted to underscores. For
example <input name="a.b" /> becomes $_POST["a_b"].
Any reason why? and any way to modify this behaviour to preserve dots
and spaces? (dots specifically)
reason, when building "linked data" / rdf based applications using PHP
it's most beneficial to use subject / predicate URIs (eg
http://xmlns.com/foaf/0.1/mbox) as form input names.
also worth noting that if you send:
<input name="a.b[c.d]" />
you'll receive the following in php:
$_POST[a_b] => array('c.d' => val)
note no conversion of c.d to c_d
regards,
Nathan
Dots and spaces in variable names are converted to underscores. For
example <input name="a.b" /> becomes $_POST["a_b"].Any reason why? and any way to modify this behaviour to preserve dots
and spaces? (dots specifically)
I'm also using dots for this reason, so I feel your pain. What I ended up
doing is converting dot syntax to PHP array syntax as I compile my
templates.
So when I type this: <input ... name="a.b.c.d"> what I get actually
compiled and sent to the browser is this: <intput ... name="a[b][c][d]">
The reason for this quirk is register_globals. The symbols not suitable for
symbol names, such as dots, are replaced with underscores, so that you can
access your POST variable "foo.bar" as $foo_bar in global space. Of course
it never made sense the conversion is applied to the superglobals like
$_COOKIE/GET/POST, but it was, and now there are claims that it'll break
backwards compatibility if changed.
I hope PHP6 will remove this processing as register_globals will be
completely removed at that point.
Regards,
Stan Vassilev
Stan Vassilev wrote:
Dots and spaces in variable names are converted to underscores. For
example <input name="a.b" /> becomes $_POST["a_b"].Any reason why? and any way to modify this behaviour to preserve dots
and spaces? (dots specifically)I'm also using dots for this reason, so I feel your pain. What I ended
up doing is converting dot syntax to PHP array syntax as I compile my
templates.
So when I type this: <input ... name="a.b.c.d"> what I get actually
compiled and sent to the browser is this: <intput ... name="a[b][c][d]">The reason for this quirk is register_globals. The symbols not
suitable for symbol names, such as dots, are replaced with
underscores, so that you can access your POST variable "foo.bar" as
$foo_bar in global space. Of course it never made sense the conversion
is applied to the superglobals like $_COOKIE/GET/POST, but it was, and
now there are claims that it'll break backwards compatibility if changed.I hope PHP6 will remove this processing as register_globals will be
completely removed at that point.
Well, that conversion still needs to happen somewhere, since plenty of
apps callextract()on those superglobals, but with register_globals
entirely gone in PHP 6, I suppose that conversion can be moved to the
extract()call.
-Rasmus
Well, that conversion still needs to happen somewhere, since plenty of
apps callextract()on those superglobals, but with register_globals
entirely gone in PHP 6, I suppose that conversion can be moved to the
extract()call.-Rasmus
Hi,
I'm not sure it needs to happen anywhere. Such symbols could be simply
referred to with the intended syntax: ${'a.b.c.d'}.
By the way, extract now seems to just ignore those vars when given an array:
extract(array('foo.bar' => 'baz'));
echo ${'foo.bar'}; // notice, no such variable
echo $foo_bar; // notice, no such variable
Regards,
Stan Vassilev
Stan Vassilev wrote:
Well, that conversion still needs to happen somewhere, since plenty
of apps callextract()on those superglobals, but with
register_globals entirely gone in PHP 6, I suppose that conversion
can be moved to theextract()call.-Rasmus
Hi,
I'm not sure it needs to happen anywhere. Such symbols could be simply
referred to with the intended syntax: ${'a.b.c.d'}.By the way, extract now seems to just ignore those vars when given an
array:extract(array('foo.bar' => 'baz'));
echo ${'foo.bar'}; // notice, no such variable
echo $foo_bar; // notice, no such variable
Right, because it expects the source array to already have been converted.
-Rasmus
Well, that conversion still needs to happen somewhere, since plenty of
apps callextract()on those superglobals, but with register_globals
entirely gone in PHP 6, I suppose that conversion can be moved to the
extract()call.-Rasmus
I'm definitely +1 on moving that logic into extract() for PHP6.
Well, that conversion still needs to happen somewhere, since plenty of
apps callextract()on those superglobals, but with register_globals
entirely gone in PHP 6, I suppose that conversion can be moved to the
extract()call.-Rasmus
I'm definitely +1 on moving that logic into
extract()for PHP6.
It'd be better to add an extra flag that will enable this new logic and
leave it off by default.
Otherwise it will break BC.
Stan Vassilev wrote:
I hope PHP6 will remove this processing as register_globals will be
completely removed at that point.
I'd be happy if it stayed like it is, for backwards compatibility. If
not, then there needs to be some reasonably straightforward way for an
app to work out how PHP has messed up its input so that it can put it
back together (compare get_magic_quotes_gpc()).
In any case, it could be better documented. I see it is documented in
these places:
http://www.php.net/manual/en/language.variables.external.php
http://www.php.net/manual/en/faq.html.php
But not in any of these places:
http://www.php.net/manual/en/reserved.variables.get.php
http://www.php.net/manual/en/reserved.variables.post.php
http://www.php.net/manual/en/reserved.variables.cookies.php
-- Tim Starling
I'd be happy if it stayed like it is, for backwards compatibility. If
not, then there needs to be some reasonably straightforward way for an
app to work out how PHP has messed up its input so that it can put it
back together (compareget_magic_quotes_gpc()).In any case, it could be better documented. I see it is documented in
these places:
Hi,
I look at this feature more as a broken compatibility with HTTP, since
there's data lost from otherwise valid field names on the way from the
server to PHP's userland.
Since the bigger feature in question (register_globals) is removed, people
who use the underscore filter with register_globals have already lost
backwards compatibility.
For those who want to emulate register_globals with extract(), they can
easily emulate the underscore filter as well (it's 3 lines of code).
Regards,
Stan Vassilev
Tim Starling wrote:
Stan Vassilev wrote:
I hope PHP6 will remove this processing as register_globals will be
completely removed at that point.I'd be happy if it stayed like it is, for backwards compatibility.
Sometimes forwards compatibility has to take precedence though.
Linked data is set to explode around the net over the next year or two;
general form fields will soon be replaced with properties from
ontologies (such as foaf), people will have personal rdf graphs housed
in their browsers and autocomplete will populate forms where the
property uri's are known; if these form elements all contain uri's with
dots swapped out with underscores then this could be a potentially big
problem for the giant global graph and PHP developers specifically.
All solved very easily by being able to ini switch this replacement
feature on and off.
on the server side..
http://example.org/ontology/0.1/some_property
becomes
http://example.org/ontology/0_1/some_property
how do you reverse replace the correct underscore with a dot?
if we use the <input
name="data[http://example.org/ontology/0.1/some_property]" /> workaround
in userland this is no doubt breaking many future browser extensions
looking for <input name="http://example.org/ontology/0.1/some_property" />
quite sure a small patch and ini switch would cater for both BC and FC
in this case; even if it was removed all together then to achieve bc
would be a simple for loop and str_replace; hardly major.
regards!
Once upon a time, a long time ago, PHP imported all GET/POST/COOKIE
data as variables, for the convenience of the developer.
This was called "register_globals"
$a.b is not a valid variable name, so it was changed to $a_b to be a
valid variable name.
Nowadays, I see no real reason to keep doing this, other than BC.
And I'm not sure who would actually use 'a.b' and then expect 'a_b',
but I have to assume somebody has done that, perhaps consuming an API
from somewhere else.
Short-term, your options are to use $_SERVER['REQUEST_URI'] and parse
it yourself, or "don't do that".
Long-term, I suggest you lobby for this to change in PHP 6, if it
isn't already in the works.
For BC, I suppose PHP could have both 'a.b' and 'a_b', or yet
another php.ini flag (sorry!) to choose the behaviour.
Dots and spaces in variable names are converted to underscores. For
example <input name="a.b" /> becomes $_POST["a_b"].Any reason why? and any way to modify this behaviour to preserve dots
and spaces? (dots specifically)reason, when building "linked data" / rdf based applications using PHP
it's most beneficial to use subject / predicate URIs (eg
http://xmlns.com/foaf/0.1/mbox) as form input names.also worth noting that if you send:
<input name="a.b[c.d]" />
you'll receive the following in php:
$_POST[a_b] => array('c.d' => val)
note no conversion of c.d to c_dregards,
Nathan
--
--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch
Richard Lynch wrote:
For BC, I suppose PHP could have both 'a.b' and 'a_b'
+1 as a PHP user. For BC, I guess this should go without changing the
current precedence rules too, annoying though it might be.
At the moment: "?a_b=foo&a.b=bar" gives $_GET === array('a_b' => 'bar')
As I understand it with this proposal: "?a_b=foo&a.b=bar" would give
$_GET === array('a_b' => 'bar', 'a.b' => 'bar')
It would be nicer for it not to lose the original assignment (a_b =>
foo) though, perhaps via an INI setting.
Dave
I have taken the liberty of making an RFC for this:
http://wiki.php.net/rfc/url_dots
Feel free to add/edit it as fit, particularly since it's my first use
of that RFC wiki, and I'm not good at wiki markup, and I probably
missed something from this thread.
I intentionally left out the ?a_b=1&a.b=2 because that seemed to me to
be beyond the scope, since ?a_b=1&a_b=2 is equally problematic in
PHP...
That said, I am now leaning towards not trying to be BC, and just
dropping 'a_b' entirely.
It seems unlikely that anybody doing anything "sane" to attempt to
reconstruct their original keys is going to be hurt by PHP not messing
them up anymore.
Most likely, their revisionary code is simply not going to find any
'a_b' to blindly revert to 'a.b' anymore, and the 'a.b' is going to
just sail through.
Of course, their a.b might be a^b or a*b or whatever, but whatever it
is, PHP not messing it up will just mean their code won't find
anything to "un-do" any more.
I did think of one other issue though:
There may be some really funky character that is valid in the URL, but
that is not kosher for an array/hash key which is currently being
masked...
It would still have to be masked if such a character exists...
I can't think of any such character, but what with i18n of DNS records
and whatnot these days, I am woefully ignorant of what might be in the
keys.
I put that into the RFC already.
--
Some people ask for gifts here.
I just want you to buy an Indie CD for yourself:
http://cdbaby.com/search/from/lynch
I have taken the liberty of making an RFC for this:
http://wiki.php.net/rfc/url_dots
thanks. looks good to me
Richard Lynch wrote:
I have taken the liberty of making an RFC for this:
http://wiki.php.net/rfc/url_dotsFeel free to add/edit it as fit, particularly since it's my first use
of that RFC wiki, and I'm not good at wiki markup, and I probably
missed something from this thread.I intentionally left out the ?a_b=1&a.b=2 because that seemed to me to
be beyond the scope, since ?a_b=1&a_b=2 is equally problematic in
PHP...That said, I am now leaning towards not trying to be BC, and just
dropping 'a_b' entirely.It seems unlikely that anybody doing anything "sane" to attempt to
reconstruct their original keys is going to be hurt by PHP not messing
them up anymore.Most likely, their revisionary code is simply not going to find any
'a_b' to blindly revert to 'a.b' anymore, and the 'a.b' is going to
just sail through.Of course, their a.b might be a^b or a*b or whatever, but whatever it
is, PHP not messing it up will just mean their code won't find
anything to "un-do" any more.I did think of one other issue though:
There may be some really funky character that is valid in the URL, but
that is not kosher for an array/hash key which is currently being
masked...It would still have to be masked if such a character exists...
I can't think of any such character, but what with i18n of DNS records
and whatnot these days, I am woefully ignorant of what might be in the
keys.I put that into the RFC already.
Thanks Richard,
I was struggling to get to time to write this up - all seems fine to me
and just as discussed on-list.
Thanks again,
Nathan
For BC, I suppose PHP could have both 'a.b' and 'a_b', or yet
another php.ini flag (sorry!) to choose the behaviour.
-1 from me.
I don't think we need to keep backward compatibility for this. PHP-6 is a major release, after all.
It would be absolutely enough to add optional var-name conversion to extract()
-1 from me.
I don't think we need to keep backward compatibility for this. PHP-6 is a major release, after all.It would be absolutely enough to add optional var-name conversion to
extract()
Agreed.
--
-Jack Timmons
http://www.trotlc.com
Twitter: @codeacula
Alexey Zakhlestin wrote:
For BC, I suppose PHP could have both 'a.b' and 'a_b', or yet
another php.ini flag (sorry!) to choose the behaviour.-1 from me.
I don't think we need to keep backward compatibility for this. PHP-6 is a major release, after all.It would be absolutely enough to add optional var-name conversion to
extract()
any word from anybody on the development team to say if this "removal of
dot conversion" (whether optional or not) can be added to some todo list
or suchlike and rolled out at some point soon~ish?
Nathan Rixham wrote:
Alexey Zakhlestin wrote:
For BC, I suppose PHP could have both 'a.b' and 'a_b', or yet
another php.ini flag (sorry!) to choose the behaviour.
-1 from me.
I don't think we need to keep backward compatibility for this. PHP-6 is a major release, after all.It would be absolutely enough to add optional var-name conversion to
extract()any word from anybody on the development team to say if this "removal of
dot conversion" (whether optional or not) can be added to some todo list
or suchlike and rolled out at some point soon~ish?
An (out of date) ToDo list is at http://wiki.php.net/todo/php60
Could you create an RFC at http://wiki.php.net/rfc to capture all the
discussion on the topic?
--
Blog: http://blogs.oracle.com/opal
Twitter: http://twitter.com/ghrd
For BC, I suppose PHP could have both 'a.b' and 'a_b', or yet
another php.ini flag (sorry!) to choose the behaviour.-1 from me.
I don't think we need to keep backward compatibility for this. PHP-6 is a
major release, after all.It would be absolutely enough to add optional var-name conversion to
extract()=
By default extract ignores variables with dots like a.b
Even though register_globals should be removed, it does not mean that the
default behaviour of extract
should be changed.
If it's necessary to provide a way to mimic register_globals
functionality, a special flag for it should
be added, something like EXTR_MIMIC_REGISTER_GLOBALS that will replaces
incorrect characters
in the variable names with underscrores.
In this case BC won't be broken.
And I'm not sure who would actually use 'a.b' and then expect 'a_b',
but I have to assume somebody has done that, perhaps consuming an API
from somewhere else.
OpedID protocol uses dots in query string arguments. The
implementations could be broken by the patch.
While the "keep arguments as is" behaviour is certainly better in the
long run - issues like OpenID should be taken into account.
2010/1/21 jvlad dmda@yandex.ru:
For BC, I suppose PHP could have both 'a.b' and 'a_b', or yet
another php.ini flag (sorry!) to choose the behaviour.-1 from me.
I don't think we need to keep backward compatibility for this. PHP-6 is a
major release, after all.It would be absolutely enough to add optional var-name conversion to
extract()=By default extract ignores variables with dots like a.b
Even though register_globals should be removed, it does not mean that the
default behaviour of extract
should be changed.
If it's necessary to provide a way to mimic register_globals
functionality, a special flag for it should
be added, something like EXTR_MIMIC_REGISTER_GLOBALS that will replaces
incorrect characters
in the variable names with underscrores.
In this case BC won't be broken.--
--
С уважением,
Виктор
And I'm not sure who would actually use 'a.b' and then expect 'a_b',
but I have to assume somebody has done that, perhaps consuming an API
from somewhere else.OpedID protocol uses dots in query string arguments. The
implementations could be broken by the patch.While the "keep arguments as is" behaviour is certainly better in the
long run - issues like OpenID should be taken into account.
Hi,
PHP6 is the long run.
Regards,
Stan Vassilev