Re: [PHP-DEV] _REQUEST and variable_order
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, February 6, 2008 6:39 pm, Stanislav Malyshev wrote: > 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): > 1. One way to fix it is to create a new .ini request_order that would > control just _REQUEST. > > 2. 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. > > 3. 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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Feb 13, 2008, at 1:50 PM, Stanislav Malyshev wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
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 [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, 13 Feb 2008, Stanislav Malyshev wrote:
> > 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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
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
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, 13 Feb 2008, Stanislav Malyshev wrote:
> > 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
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
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
Index: php.ini-dist
===
RCS file: /repository/php-src/php.ini-dist,v
retrieving revision 1.231.2.10.2.22.2.2
diff -u -r1.231.2.10.2.22.2.2 php.ini-dist
--- php.ini-dist11 Feb 2008 00:01:11 - 1.231.2.10.2.22.2.2
+++ php.ini-dist13 Feb 2008 20:57:20 -
@@ -413,6 +413,12 @@
; values override older values.
variables_order = "EGPCS"
+; This directive describes the order in which PHP registers GET, POST and
Cookie
+; variables into the _REQUEST array. Registration is done from left to right,
+; newer values override older values.
+; If this directive is not set, variables_order is used for _REQUEST contents.
+; request_order = "GP"
+
; Whether or not to register the EGPCS variables as global variables. You may
; want to turn this off if you don't want to clutter your scripts' global scope
; with user data. This makes most sense when coupled with track_vars - in
which
Index: php.ini-recommended
===
RCS file: /repository/php-src/php.ini-recommended,v
retrieving revision 1.179.2.11.2.23.2.2
diff -u -r1.179.2.11.2.23.2.2 php.ini-recommended
--- php.ini-recommended 11 Feb 2008 00:01:11 - 1.179.2.11.2.23.2.2
+++ php.ini-recommended 13 Feb 2008 20:57:20 -
@@ -464,6 +464,12 @@
; values override older values.
variables_order = "GPCS"
+; This directive describes the order in which PHP registers GET, POST and
Cookie
+; variables into the _REQUEST array. Registration is done from left to right,
+; newer values override older values.
+; If this directive is not set, variables_order is used for _REQUEST contents.
+request_order = "GP"
+
; Whether or not to register the EGPCS variables as global variables. You may
; want to turn this off if you don't want to clutter your scripts' global scope
; with user data. This makes most sense when coupled with track_vars - in
which
Index: main/main.c
===
RCS file: /repository/php-src/main/main.c,v
retrieving revision 1.640.2.23.2.57.2.8
diff -u -r1.640.2.23.2.57.2.8 main.c
--- main/main.c 4 Feb 2008 20:39:21 - 1.640.2.23.2.57.2.8
+++ main/main.c 13 Feb 2008 20:57:20 -
@@ -436,6 +436,7 @@
STD_PHP_INI_ENTRY("user_dir", NULL,
PHP_INI_SYSTEM, OnUpdateString, user_dir,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY("variables_order","EGPCS",
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateStringUnempty,
variables_order,php_core_globals, core_globals)
+ STD_PHP_INI_ENTRY("request_order", NULL,
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateString, request_order,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY("error_append_string",NULL,
PHP_INI_ALL,OnUpdateString, error_append_string,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY("error_prepend_string", NULL,
PHP_INI_ALL,OnUpdateString, error_prepend_string,
php_core_globals, core_globals)
Index: main/php_globals.h
===
RCS file: /repository/php-src/main/php_globals.h,v
retrieving revision 1.98.2.1.2.7.2.2
diff -u -r1.98.2.1.2.7.2.2 php_globals.h
--- main/php_globals.h 31 Dec 2007 07:17:17 - 1.98.2.1.2.7.2.2
+++ main/php_globals.h 13 Feb 2008 20:57:20 -
@@ -164,6 +164,8 @@
char *user_ini_filename;
long user_ini_cache_ttl;
+
+ char *request_order;
};
Index: main/php_variables.c
===
RCS file: /repository/php-src/main/php_variables.c,v
retrieving revision 1.104.2.10.2.11.2.3
diff -u -r1.104.2.10.2.11.2.3 php_variables.c
--- main/php_variables.c31 Dec 2007 07:17:17 -
1.104.2.10.2.11.2.3
+++ main/php_variables.c13 Feb 2008 20:57:20 -
@@ -835,7 +835,13 @@
array_init(form_variables);
INIT_PZVAL(form_variables);
- for (p = PG(variables_order); p && *p; p++) {
+ if(PG(request_order) != NULL) {
+ p = PG(request_order);
+ } else {
+ p = PG(variables_order);
+ }
+
+ for (; p && *p; p++) {
switch (*p) {
case 'g':
case 'G':
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, 6 Feb 2008, Stanislav Malyshev wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Thu, 2008-02-07 at 02:17 -0800, Rasmus Lerdorf wrote: > Jani Taskinen wrote: > > On Thu, 2008-02-07 at 01:43 -0800, Rasmus Lerdorf wrote: > >> Jani Taskinen wrote: > >>> On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf wrote: > Stanislav Malyshev wrote: > > The proposal(s): > > 1. One way to fix it is to create a new .ini request_order that would > > control just _REQUEST. > > > > 2. 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. > > > > 3. 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-order > > > > But 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
Am 07.02.2008 um 11:02 schrieb Jani Taskinen: On Thu, 2008-02-07 at 01:43 -0800, Rasmus Lerdorf wrote: 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? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
A minor clarification: The auto-globals are always there, they're not always _populated_ though. (JIC someone misunderstood this part :) On Thu, 2008-02-07 at 02:17 -0800, Rasmus Lerdorf wrote: [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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
Jani Taskinen wrote: > On Thu, 2008-02-07 at 01:43 -0800, Rasmus Lerdorf wrote: >> Jani Taskinen wrote: >>> On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf wrote: Stanislav Malyshev wrote: > The proposal(s): > 1. One way to fix it is to create a new .ini request_order that would > control just _REQUEST. > > 2. 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. > > 3. 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-order > > But 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Thu, 2008-02-07 at 01:43 -0800, Rasmus Lerdorf wrote: > Jani Taskinen wrote: > > On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf wrote: > >> Stanislav Malyshev wrote: > >>> The proposal(s): > >>> 1. One way to fix it is to create a new .ini request_order that would > >>> control just _REQUEST. > >>> > >>> 2. 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. > >>> > >>> 3. 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
Jani Taskinen wrote: > On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf 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): >>> 1. One way to fix it is to create a new .ini request_order that would >>> control just _REQUEST. >>> >>> 2. 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. >>> >>> 3. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf 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): > > 1. One way to fix it is to create a new .ini request_order that would > > control just _REQUEST. > > > > 2. 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. > > > > 3. 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, 2008-02-06 at 20:27 -0800, Rasmus Lerdorf 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): > > 1. One way to fix it is to create a new .ini request_order that would > > control just _REQUEST. > > > > 2. 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. > > > > 3. 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
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): > 1. One way to fix it is to create a new .ini request_order that would > control just _REQUEST. > > 2. 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. > > 3. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
Sam Barrow wrote: On Wed, 2008-02-06 at 16:39 -0800, Stanislav Malyshev wrote: [snip] The proposal(s): 1. One way to fix it is to create a new .ini request_order that would control just _REQUEST. 2. 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) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, 2008-02-06 at 16:39 -0800, 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): > 1. One way to fix it is to create a new .ini request_order that would > control just _REQUEST. > > 2. 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. > 3. 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 > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
