Hi!
This topic was already discussed here but never arrived to a conclusion,
so I will raise it again.
The Problem:
We have $_REQUEST superglobal, which is often used to abstract GET/POST
requests. However, in most cases we do not want GET/POST variables to
mean the same as cookie and environment variables. We can avoid that by
setting variables_order to 'GP' but then we lose _SERVER and _COOKIES
which still can be very much useful. We cannot also reliably use
something like 'CGP' since while it won't allow cookies to override
GET/POST we still have no way of not accepting cookie that has no
matching GET/POST. I think this should be cleaned up so that _REQUEST
behavior would conform its use case.
The proposal(s):
-
One way to fix it is to create a new .ini request_order that would
control just _REQUEST. -
Other solution would be to keep variables_order but drop 'C' parsing
from _REQUEST - i.e. make _REQUEST never include cookies. I don't know
how many people really need cookies together with get/post in REQUEST. -
Yet another solution would be to make superglobals independent of
variables_order - i.e. _COOKIE would always exist even if
variables_order doesn't have the letter. I actually don't see any reason
having JIT to remove any of the superglobals - if you don't use them,
with JIT you don't pay for them. And with COOKIES it's not that it would
be a big cost anyway - how many cookies could you have?
Of course, it'd be more substantial change which could break some apps
relying on some quirks of current behavior.
So, what do you think on this?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
This topic was already discussed here but never arrived to a conclusion,
so I will raise it again.
The Problem:
We have $_REQUEST superglobal, which is often used to abstract GET/POST
requests. However, in most cases we do not want GET/POST variables to
mean the same as cookie and environment variables. We can avoid that by
setting variables_order to 'GP' but then we lose _SERVER and _COOKIES
which still can be very much useful. We cannot also reliably use
something like 'CGP' since while it won't allow cookies to override
GET/POST we still have no way of not accepting cookie that has no
matching GET/POST. I think this should be cleaned up so that _REQUEST
behavior would conform its use case.The proposal(s):
One way to fix it is to create a new .ini request_order that would
control just _REQUEST.Other solution would be to keep variables_order but drop 'C' parsing
from _REQUEST - i.e. make _REQUEST never include cookies. I don't know
how many people really need cookies together with get/post in REQUEST.
I like this. $_REQUEST is used by me and most PHP developers I know
solely for the purpose of abstracting $_GET and $_POST. But user input
never comes directly from cookies (what user fills in a login form by
setting cookies?), so I don't see a point of including them.
- Yet another solution would be to make superglobals independent of
variables_order - i.e. _COOKIE would always exist even if
variables_order doesn't have the letter. I actually don't see any reason
having JIT to remove any of the superglobals - if you don't use them,
with JIT you don't pay for them. And with COOKIES it's not that it would
be a big cost anyway - how many cookies could you have?
Of course, it'd be more substantial change which could break some apps
relying on some quirks of current behavior.So, what do you think on this?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Sam Barrow wrote:
[snip]
The proposal(s):
One way to fix it is to create a new .ini request_order that would
control just _REQUEST.Other solution would be to keep variables_order but drop 'C' parsing
from _REQUEST - i.e. make _REQUEST never include cookies. I don't know
how many people really need cookies together with get/post in REQUEST.I like this. $_REQUEST is used by me and most PHP developers I know
solely for the purpose of abstracting $_GET and $_POST. But user input
never comes directly from cookies (what user fills in a login form by
setting cookies?), so I don't see a point of including them.
I also like solution #2, I always read cookies using $_COOKIE.
--
Jessie Hernandez
Zend Certified Engineer (http://zend.com/zce.php?c=ZEND006359&r=222727282)
Stanislav Malyshev wrote:
Hi!
This topic was already discussed here but never arrived to a conclusion,
so I will raise it again.
The Problem:
We have $_REQUEST superglobal, which is often used to abstract GET/POST
requests. However, in most cases we do not want GET/POST variables to
mean the same as cookie and environment variables. We can avoid that by
setting variables_order to 'GP' but then we lose _SERVER and _COOKIES
which still can be very much useful. We cannot also reliably use
something like 'CGP' since while it won't allow cookies to override
GET/POST we still have no way of not accepting cookie that has no
matching GET/POST. I think this should be cleaned up so that _REQUEST
behavior would conform its use case.The proposal(s):
One way to fix it is to create a new .ini request_order that would
control just _REQUEST.Other solution would be to keep variables_order but drop 'C' parsing
from _REQUEST - i.e. make _REQUEST never include cookies. I don't know
how many people really need cookies together with get/post in REQUEST.Yet another solution would be to make superglobals independent of
variables_order - i.e. _COOKIE would always exist even if
variables_order doesn't have the letter. I actually don't see any reason
having JIT to remove any of the superglobals - if you don't use them,
with JIT you don't pay for them. And with COOKIES it's not that it would
be a big cost anyway - how many cookies could you have?
Of course, it'd be more substantial change which could break some apps
relying on some quirks of current behavior.So, what do you think on this?
They are all about equivalent. Even #3 would need some sort of ini
override since otherwise it removes some flexibility we have today.
There are setups that specifically rely on disabling $_COOKIE to force
code to go through other mechanisms to get at the cookies.
Perhaps a combination of 1 and 2. By default drop cookies from
$_REQUEST but have an ini override for the few cases where the app
actually relies on this behaviour. I have seen multi-page forms where
instead of bouncing previous inputs along in hidden fields it gets
transmitted in cookies and they use $_REQUEST to keep track of all of
the responses.
-Rasmus
Stanislav Malyshev wrote:
Hi!
This topic was already discussed here but never arrived to a conclusion,
so I will raise it again.
The Problem:
We have $_REQUEST superglobal, which is often used to abstract GET/POST
requests. However, in most cases we do not want GET/POST variables to
mean the same as cookie and environment variables. We can avoid that by
setting variables_order to 'GP' but then we lose _SERVER and _COOKIES
which still can be very much useful. We cannot also reliably use
something like 'CGP' since while it won't allow cookies to override
GET/POST we still have no way of not accepting cookie that has no
matching GET/POST. I think this should be cleaned up so that _REQUEST
behavior would conform its use case.The proposal(s):
One way to fix it is to create a new .ini request_order that would
control just _REQUEST.Other solution would be to keep variables_order but drop 'C' parsing
from _REQUEST - i.e. make _REQUEST never include cookies. I don't know
how many people really need cookies together with get/post in REQUEST.Yet another solution would be to make superglobals independent of
variables_order - i.e. _COOKIE would always exist even if
variables_order doesn't have the letter. I actually don't see any reason
having JIT to remove any of the superglobals - if you don't use them,
with JIT you don't pay for them. And with COOKIES it's not that it would
be a big cost anyway - how many cookies could you have?
Of course, it'd be more substantial change which could break some apps
relying on some quirks of current behavior.So, what do you think on this?
They are all about equivalent. Even #3 would need some sort of ini
override since otherwise it removes some flexibility we have today.
There are setups that specifically rely on disabling $_COOKIE to force
code to go through other mechanisms to get at the cookies.Perhaps a combination of 1 and 2. By default drop cookies from
$_REQUEST but have an ini override for the few cases where the app
actually relies on this behaviour. I have seen multi-page forms where
instead of bouncing previous inputs along in hidden fields it gets
transmitted in cookies and they use $_REQUEST to keep track of all of
the responses.
True. Why not an ini setting, request_variables that works the same as
variables_order, just for $_REQUEST.
-Rasmus
Stanislav Malyshev wrote:
Hi!
This topic was already discussed here but never arrived to a conclusion,
so I will raise it again.
The Problem:
We have $_REQUEST superglobal, which is often used to abstract GET/POST
requests. However, in most cases we do not want GET/POST variables to
mean the same as cookie and environment variables. We can avoid that by
setting variables_order to 'GP' but then we lose _SERVER and _COOKIES
which still can be very much useful. We cannot also reliably use
something like 'CGP' since while it won't allow cookies to override
GET/POST we still have no way of not accepting cookie that has no
matching GET/POST. I think this should be cleaned up so that _REQUEST
behavior would conform its use case.The proposal(s):
One way to fix it is to create a new .ini request_order that would
control just _REQUEST.Other solution would be to keep variables_order but drop 'C' parsing
from _REQUEST - i.e. make _REQUEST never include cookies. I don't know
how many people really need cookies together with get/post in REQUEST.Yet another solution would be to make superglobals independent of
variables_order - i.e. _COOKIE would always exist even if
variables_order doesn't have the letter. I actually don't see any reason
having JIT to remove any of the superglobals - if you don't use them,
with JIT you don't pay for them. And with COOKIES it's not that it would
be a big cost anyway - how many cookies could you have?
Of course, it'd be more substantial change which could break some apps
relying on some quirks of current behavior.So, what do you think on this?
They are all about equivalent. Even #3 would need some sort of ini
override since otherwise it removes some flexibility we have today.
There are setups that specifically rely on disabling $_COOKIE to force
code to go through other mechanisms to get at the cookies.Perhaps a combination of 1 and 2. By default drop cookies from
$_REQUEST but have an ini override for the few cases where the app
actually relies on this behaviour. I have seen multi-page forms where
instead of bouncing previous inputs along in hidden fields it gets
transmitted in cookies and they use $_REQUEST to keep track of all of
the responses.
What's wrong with the option 3? $_GET / $_POST / $_COOKIE should
always be there regardless of any ini setting. I didn't even know
(before Stas brought it up) that variables_order affects these so in my
book that's just a bug that needs fixing. And does not require any new
ini options.. :)
I pick door #3.
--
Patches/Donations: http://pecl.php.net/~jani/
Jani Taskinen wrote:
Stanislav Malyshev wrote:
Hi!
This topic was already discussed here but never arrived to a conclusion,
so I will raise it again.
The Problem:
We have $_REQUEST superglobal, which is often used to abstract GET/POST
requests. However, in most cases we do not want GET/POST variables to
mean the same as cookie and environment variables. We can avoid that by
setting variables_order to 'GP' but then we lose _SERVER and _COOKIES
which still can be very much useful. We cannot also reliably use
something like 'CGP' since while it won't allow cookies to override
GET/POST we still have no way of not accepting cookie that has no
matching GET/POST. I think this should be cleaned up so that _REQUEST
behavior would conform its use case.The proposal(s):
One way to fix it is to create a new .ini request_order that would
control just _REQUEST.Other solution would be to keep variables_order but drop 'C' parsing
from _REQUEST - i.e. make _REQUEST never include cookies. I don't know
how many people really need cookies together with get/post in REQUEST.Yet another solution would be to make superglobals independent of
variables_order - i.e. _COOKIE would always exist even if
variables_order doesn't have the letter. I actually don't see any reason
having JIT to remove any of the superglobals - if you don't use them,
with JIT you don't pay for them. And with COOKIES it's not that it would
be a big cost anyway - how many cookies could you have?
Of course, it'd be more substantial change which could break some apps
relying on some quirks of current behavior.So, what do you think on this?
They are all about equivalent. Even #3 would need some sort of ini
override since otherwise it removes some flexibility we have today.
There are setups that specifically rely on disabling $_COOKIE to force
code to go through other mechanisms to get at the cookies.Perhaps a combination of 1 and 2. By default drop cookies from
$_REQUEST but have an ini override for the few cases where the app
actually relies on this behaviour. I have seen multi-page forms where
instead of bouncing previous inputs along in hidden fields it gets
transmitted in cookies and they use $_REQUEST to keep track of all of
the responses.What's wrong with the option 3? $_GET / $_POST / $_COOKIE should
always be there regardless of any ini setting. I didn't even know
(before Stas brought it up) that variables_order affects these so in my
book that's just a bug that needs fixing. And does not require any new
ini options.. :)I pick door #3.
Well, plenty of people know about this feature and make use of it.
Especially since it has been documented to work this way for a long time.
See: http://php.net/manual/en/ini.core.php#ini.variables-order
"Sets the order of the EGPCS (Environment, Get, Post, Cookie, and
Server) variable parsing. For example, if variables_order is set to
"SP" then PHP will create the superglobals $_SERVER and $_POST, but not
create $_ENV, $_GET, and $_COOKIE. Setting to "" means no superglobals
will be set."
-Rasmus
Jani Taskinen wrote:
Stanislav Malyshev wrote:
The proposal(s):
One way to fix it is to create a new .ini request_order that would
control just _REQUEST.Other solution would be to keep variables_order but drop 'C' parsing
from _REQUEST - i.e. make _REQUEST never include cookies. I don't know
how many people really need cookies together with get/post in REQUEST.Yet another solution would be to make superglobals independent of
variables_order - i.e. _COOKIE would always exist even if
variables_order doesn't have the letter. I actually don't see any reason
having JIT to remove any of the superglobals - if you don't use them,
with JIT you don't pay for them. And with COOKIES it's not that it would
be a big cost anyway - how many cookies could you have?
Of course, it'd be more substantial change which could break some apps
relying on some quirks of current behavior.So, what do you think on this?
They are all about equivalent. Even #3 would need some sort of ini
override since otherwise it removes some flexibility we have today.
There are setups that specifically rely on disabling $_COOKIE to force
code to go through other mechanisms to get at the cookies.
I missed this from your mail. Sounds a very weird idea, do they set
$_COOKIE themselves then? And can I ask where such setup is used?
I pick door #3.
Well, plenty of people know about this feature and make use of it.
Especially since it has been documented to work this way for a long time.
See: http://php.net/manual/en/ini.core.php#ini.variables-order
But was it really designed to work like that? :)
Anyway, I guess there's no other way out of this than creating another
ini option, say "request_variables_order" which controls whatever goes
in $_REQUEST. But would the "variables_order" still control the overal
situation? For example when it is set to "GP" and
"request_variables_order" is set to "GPC", would $_REQUEST have all of
$_GET / $_POST / $_COOKIE regardless what "variables_order" has in it?
--Jani
--
Patches/Donations: http://pecl.php.net/~jani/
Jani Taskinen wrote:
Jani Taskinen wrote:
Stanislav Malyshev wrote:
The proposal(s):
One way to fix it is to create a new .ini request_order that would
control just _REQUEST.Other solution would be to keep variables_order but drop 'C' parsing
from _REQUEST - i.e. make _REQUEST never include cookies. I don't know
how many people really need cookies together with get/post in REQUEST.Yet another solution would be to make superglobals independent of
variables_order - i.e. _COOKIE would always exist even if
variables_order doesn't have the letter. I actually don't see any reason
having JIT to remove any of the superglobals - if you don't use them,
with JIT you don't pay for them. And with COOKIES it's not that it would
be a big cost anyway - how many cookies could you have?
Of course, it'd be more substantial change which could break some apps
relying on some quirks of current behavior.So, what do you think on this?
They are all about equivalent. Even #3 would need some sort of ini
override since otherwise it removes some flexibility we have today.
There are setups that specifically rely on disabling $_COOKIE to force
code to go through other mechanisms to get at the cookies.I missed this from your mail. Sounds a very weird idea, do they set
$_COOKIE themselves then? And can I ask where such setup is used?
Very large sites with signed and encrypted cookies containing lots of
sub-parts will typically want to only decrypt and validate these cookies
once. Likely before they even get to PHP and provide an API to get at
them instead of having all the bits downstream each try to parse the raw
$_COOKIE value. Being able to turn off $_COOKIE altogether helps make
sure everyone follows that approach.
I pick door #3.
Well, plenty of people know about this feature and make use of it.
Especially since it has been documented to work this way for a long time.
See: http://php.net/manual/en/ini.core.php#ini.variables-orderBut was it really designed to work like that? :)
It was actually. Initially it was designed that way for performance
reasons. Populating $_ENV on every single request if you weren't going
to use it made no sense. This was obviously pre-JIT. In a pre-JIT
world being able to disable these made a lot of sense. Now the
performance reason is mostly gone, but it still leaves us with
applications that don't expect them to be there. Worst-case we have
configurations that explicitly have turned them off and create their own
$_COOKIE array to implement a local security policy. Having the
superglobal show up and populate what they thought was a locally created
array could cause security problems.
Anyway, I guess there's no other way out of this than creating another
ini option, say "request_variables_order" which controls whatever goes
in $_REQUEST. But would the "variables_order" still control the overal
situation? For example when it is set to "GP" and
"request_variables_order" is set to "GPC", would $_REQUEST have all of
$_GET / $_POST / $_COOKIE regardless what "variables_order" has in it?
The less we change, the better. That includes the meanings of existing
directives. We should focus on the actual problem and make the fewest
changes possible to solve that. The actual problem being that by
default cookie data is in $_REQUEST and that can lead to problems. So,
we change that default. Now, in the few cases out there where someone
really does want cookie data in $_REQUEST we can provide an ini for them
to enable that. Since today we don't have the ability to have cookie
data in $_REQUEST without also having $_COOKIE present, we won't break
anything by not supporting that edge case. So I think we can tie the
two together and perhaps throw a startup error if someone tries to make
$_REQUEST contain cookie data if variables_order does not include "C"
-Rasmus
A minor clarification: The auto-globals are always there, they're not
always populated though. (JIC someone misunderstood this part :)
[clip]
directives. We should focus on the actual problem and make the fewest
changes possible to solve that. The actual problem being that by
default cookie data is in $_REQUEST and that can lead to problems. So,
we change that default. Now, in the few cases out there where someone
So instead of EGPCS the default value of variables_order will be EGPS?
really does want cookie data in $_REQUEST we can provide an ini for them
to enable that. Since today we don't have the ability to have cookie
data in $_REQUEST without also having $_COOKIE present, we won't break
anything by not supporting that edge case. So I think we can tie the
two together and perhaps throw a startup error if someone tries to make
$_REQUEST contain cookie data if variables_order does not include "C"
Sounds reasonable. OTOH, what's keeping us from populating the $_REQUEST
global "on-demand"? So even if C is not in variables_order but is set in
request_variables_order the entries for '$_COOKIE' would be in $_REQUEST
but $_COOKIE itself would be empty still. By quick glance to the code
would suggest that it should be fairly easy to check in
php_auto_globals_create_request() if e.g.
Z_ARRVAL_P(PG(http_globals)[TRACK_VARS_COOKIE] is populated or not and
if not, call sapi_module.treat_data() there.
--Jani
--
Patches/Donations: http://pecl.php.net/~jani/
Jani Taskinen wrote:
Jani Taskinen wrote:
Stanislav Malyshev wrote:
The proposal(s):
One way to fix it is to create a new .ini request_order that would
control just _REQUEST.Other solution would be to keep variables_order but drop 'C' parsing
from _REQUEST - i.e. make _REQUEST never include cookies. I don't know
how many people really need cookies together with get/post in REQUEST.Yet another solution would be to make superglobals independent of
variables_order - i.e. _COOKIE would always exist even if
variables_order doesn't have the letter. I actually don't see any reason
having JIT to remove any of the superglobals - if you don't use them,
with JIT you don't pay for them. And with COOKIES it's not that it would
be a big cost anyway - how many cookies could you have?
Of course, it'd be more substantial change which could break some apps
relying on some quirks of current behavior.So, what do you think on this?
They are all about equivalent. Even #3 would need some sort of ini
override since otherwise it removes some flexibility we have today.
There are setups that specifically rely on disabling $_COOKIE to force
code to go through other mechanisms to get at the cookies.I missed this from your mail. Sounds a very weird idea, do they set
$_COOKIE themselves then? And can I ask where such setup is used?Very large sites with signed and encrypted cookies containing lots of
sub-parts will typically want to only decrypt and validate these cookies
once. Likely before they even get to PHP and provide an API to get at
them instead of having all the bits downstream each try to parse the raw
$_COOKIE value. Being able to turn off $_COOKIE altogether helps make
sure everyone follows that approach.I pick door #3.
Well, plenty of people know about this feature and make use of it.
Especially since it has been documented to work this way for a long time.
See: http://php.net/manual/en/ini.core.php#ini.variables-orderBut was it really designed to work like that? :)
It was actually. Initially it was designed that way for performance
reasons. Populating $_ENV on every single request if you weren't going
to use it made no sense. This was obviously pre-JIT. In a pre-JIT
world being able to disable these made a lot of sense. Now the
performance reason is mostly gone, but it still leaves us with
applications that don't expect them to be there. Worst-case we have
configurations that explicitly have turned them off and create their own
$_COOKIE array to implement a local security policy. Having the
superglobal show up and populate what they thought was a locally created
array could cause security problems.Anyway, I guess there's no other way out of this than creating another
ini option, say "request_variables_order" which controls whatever goes
in $_REQUEST. But would the "variables_order" still control the overal
situation? For example when it is set to "GP" and
"request_variables_order" is set to "GPC", would $_REQUEST have all of
$_GET / $_POST / $_COOKIE regardless what "variables_order" has in it?The less we change, the better. That includes the meanings of existing
directives. We should focus on the actual problem and make the fewest
changes possible to solve that. The actual problem being that by
default cookie data is in $_REQUEST and that can lead to problems. So,
we change that default. Now, in the few cases out there where someone
really does want cookie data in $_REQUEST we can provide an ini for them
to enable that. Since today we don't have the ability to have cookie
data in $_REQUEST without also having $_COOKIE present, we won't break
anything by not supporting that edge case. So I think we can tie the
two together and perhaps throw a startup error if someone tries to make
$_REQUEST contain cookie data if variables_order does not include "C"
I agree with this. Either a compatibility setting like
request_include_cookie or an ini setting allowing you to completely
control the content in request (as well as order of precedence). For
example, request_order = GPC, GP, PG, ...
-Rasmus
Am 07.02.2008 um 11:02 schrieb Jani Taskinen:
Well, plenty of people know about this feature and make use of it.
Especially since it has been documented to work this way for a long
time.
See: http://php.net/manual/en/ini.core.php#ini.variables-orderBut was it really designed to work like that? :)
Anyway, I guess there's no other way out of this than creating another
ini option, say "request_variables_order" which controls whatever goes
in $_REQUEST. But would the "variables_order" still control the overal
situation? For example when it is set to "GP" and
"request_variables_order" is set to "GPC", would $_REQUEST have all of
$_GET / $_POST / $_COOKIE regardless what "variables_order" has in it?
Mh, "request_variables_order" is probably not the best idea given it
can be pretty confusing when compared to "variables_order" - and nore
so if you look at what "variables_order" really does; the only "order"
it defines is that of the $_REQUEST merging, but I doubt many people
know that removing something from that var also suppressed the
respective superglobal entirely.
Maybe "request_populate_order" or so?
- David
So, what do you think on this?
Don't care so much about it, as long as the defaults keep the same like
they are now.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
matching GET/POST. I think this should be cleaned up so that _REQUEST
behavior would conform its use case.
Attached is the patch that implements request_order .ini value. Comments?
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
matching GET/POST. I think this should be cleaned up so that _REQUEST
behavior would conform its use case.Attached is the patch that implements request_order .ini value. Comments?
Yes... I didn't seem to see a default:
-
STD_PHP_INI_ENTRY("request_order", NULL, PHP_INI_SYSTEM|PHP_INI_PERDIR,OnUpdateString, request_order, php_core_globals, core_globals)
Which means that without this setting, nothing ends up in request. The
default should be what it is now ("GPC"). The same is true for
php.ini-dist - it should mention the default (still commented out, just
like the rest) as "GPC" too.
regards,
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
Yes... I didn't seem to see a default:
STD_PHP_INI_ENTRY("request_order", NULL, PHP_INI_SYSTEM|PHP_INI_PERDIR,OnUpdateString, request_order, php_core_globals, core_globals)Which means that without this setting, nothing ends up in request. The
NULL means variable_order is used.
php.ini-dist - it should mention the default (still commented out, just
like the rest) as "GPC" too.
Setting this as GPC gives wrong idea - recommended setting is GP, as C
is useful only in very rare situations for special applications.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Yes... I didn't seem to see a default:
STD_PHP_INI_ENTRY("request_order", NULL,PHP_INI_SYSTEM|PHP_INI_PERDIR,OnUpdateString, request_order,
php_core_globals, core_globals)Which means that without this setting, nothing ends up in request. The
NULLmeans variable_order is used.php.ini-dist - it should mention the default (still commented out, just like
the rest) as "GPC" too.Setting this as GPC gives wrong idea - recommended setting is GP, as C is
useful only in very rare situations for special applications.
Yes, that's why php.ini-recommended should have GP. However,
php.ini-dist documents the default - which should be GPC, like it is
right now.
regards,
Derick
--
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org
Yes, that's why php.ini-recommended should have GP. However,
php.ini-dist documents the default - which should be GPC, like it is
right now.
The default is NULL, which means using variables_order - just as before.
I don't see a lot of reason to change it to GPC - it would be neither
old compatible way (using variables_order) nor new recommended way
(using request_order=GP).
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Yes, that's why php.ini-recommended should have GP. However,
php.ini-dist documents the default - which should be GPC, like
it is right now.The default is NULL, which means using variables_order - just as
before. I don't see a lot of reason to change it to GPC - it would
be neither old compatible way (using variables_order) nor new
recommended way (using request_order=GP).
The default behaviour is proper in php.ini-dist and GPC is the
default if no php.ini exists. The use of GP should be documented in
php.ini-recommended like the other changes there, but php.ini-dist is
not the place for that except it should mention that variables_order
is the default like it currently does in the patch.
Regards,
Philip
This topic was already discussed here but never arrived to a
conclusion,
so I will raise it again.
The Problem:
We have $_REQUEST superglobal, which is often used to abstract
GET/POST
requests. However, in most cases we do not want GET/POST variables to
mean the same as cookie and environment variables. We can avoid that
by
setting variables_order to 'GP' but then we lose _SERVER and _COOKIES
which still can be very much useful. We cannot also reliably use
something like 'CGP' since while it won't allow cookies to override
GET/POST we still have no way of not accepting cookie that has no
matching GET/POST. I think this should be cleaned up so that _REQUEST
behavior would conform its use case.The proposal(s):
One way to fix it is to create a new .ini request_order that would
control just _REQUEST.Other solution would be to keep variables_order but drop 'C'
parsing
from _REQUEST - i.e. make _REQUEST never include cookies. I don't know
how many people really need cookies together with get/post in REQUEST.Yet another solution would be to make superglobals independent of
variables_order - i.e. _COOKIE would always exist even if
variables_order doesn't have the letter. I actually don't see any
reason
having JIT to remove any of the superglobals - if you don't use them,
with JIT you don't pay for them. And with COOKIES it's not that it
would
be a big cost anyway - how many cookies could you have?
Of course, it'd be more substantial change which could break some apps
relying on some quirks of current behavior.So, what do you think on this?
I would like to see $_REQUEST be just GET | POST
I also see no reason to not keep $_GET if 'G' is missing from GPC
ordering, so that would be a fine second choice.
Introducing yet another php.ini setting to fix this for the number of
people it affects seems a bit like the old cannon for a fly solution
to this naive reader.
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?
I would like to see $_REQUEST be just GET | POST
That's what ini-recommended is configured for.
I also see no reason to not keep $_GET if 'G' is missing from GPC
ordering, so that would be a fine second choice.
That changes semantics of existing switch, so I don't feel comfortable
to do such change...
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com