Before writing up a full RFC I want to put out a feeler on something.
Currently we have several input parameter objects, chief among them
$_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
of them are arrays and legacy code sometimes writes to them. Locking
them as read only objects would cause a major BC break.
What if instead we had an Object called $_PARAMETERS which holds the
read only copies of this data. In addition, this would be the first
superglobal object, able to perform some filtering of inputs. Basic
idea..
$_PARAMETERS
->get
->post
->cookie
->headers (The client http headers)
All of these would be array objects, and all would be read only and
have these methods and properties
->filtered: Copy of the array according to the current set filters of
the object.
->setFilters(): Sets the filters of the input, an array with constant
values for the allowed types.
And I'll stop there. The basic idea, to add a read only input hive
with some basic object functionality for filtering.
Personally, I don't like this. We already have $_REQUEST which can accommodate GET, POST, and COOKIE. I believe it should be up to framework/API authors to implement there own methodologies behind accessing this data. Additional functionality such as setting filters would be a part of that as well.
That said, if you're serious about the idea, a RFC would be helpful in understanding the full extent that you're suggesting.
--
Will Fitch
Before writing up a full RFC I want to put out a feeler on something.
Currently we have several input parameter objects, chief among them
$_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
of them are arrays and legacy code sometimes writes to them. Locking
them as read only objects would cause a major BC break.What if instead we had an Object called $_PARAMETERS which holds the
read only copies of this data. In addition, this would be the first
superglobal object, able to perform some filtering of inputs. Basic
idea..$_PARAMETERS
->get
->post
->cookie
->headers (The client http headers)All of these would be array objects, and all would be read only and
have these methods and properties->filtered: Copy of the array according to the current set filters of
the object.
->setFilters(): Sets the filters of the input, an array with constant
values for the allowed types.And I'll stop there. The basic idea, to add a read only input hive
with some basic object functionality for filtering.
$_REQUEST does nothing of the sort, and it's use is dangerous in
RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
and $_COOKIE, in that order but the php.ini directive can change it.
Hence there's no way of knowing if $_REQUEST['password'] came from
$_COOKIE, $_POST, or $_GET, and worse, if two values in those source
arrays have the same key $_REQUEST will overwrite them. $_REQUEST to
be honest, is a lame shortcut and bad idea almost on par with
register_globals.
I'm not recommending $_REQUEST.
$_PARAMETERS is an object, not an array. I suppose if treated like an
array it could behave like request - but I deeply dislike that idea
because it is a repeat of the mistake of $_REQUEST.
To get a value from a get request I'd use $_PARAMETERS->get['myVar'];
To get it's filtered value I'd use $_PARAMETERS->get->filtered['myVar']
To set those filters I'd use $_PARAMETERS->get->setFilters( $filters );
Personally, I don't like this. We already have $_REQUEST which can
accommodate GET, POST, and COOKIE. I believe it should be up to
framework/API authors to implement there own methodologies behind accessing
this data. Additional functionality such as setting filters would be a part
of that as well.That said, if you're serious about the idea, a RFC would be helpful in
understanding the full extent that you're suggesting.--
Will FitchBefore writing up a full RFC I want to put out a feeler on something.
Currently we have several input parameter objects, chief among them
$_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
of them are arrays and legacy code sometimes writes to them. Locking
them as read only objects would cause a major BC break.What if instead we had an Object called $_PARAMETERS which holds the
read only copies of this data. In addition, this would be the first
superglobal object, able to perform some filtering of inputs. Basic
idea..$_PARAMETERS
->get
->post
->cookie
->headers (The client http headers)All of these would be array objects, and all would be read only and
have these methods and properties->filtered: Copy of the array according to the current set filters of
the object.
->setFilters(): Sets the filters of the input, an array with constant
values for the allowed types.And I'll stop there. The basic idea, to add a read only input hive
with some basic object functionality for filtering.
$_REQUEST does nothing of the sort, and it's use is dangerous in
RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
and $_COOKIE, in that order but the php.ini directive can change it.
Hence there's no way of knowing if $_REQUEST['password'] came from
$_COOKIE, $_POST, or $_GET, and worse, if two values in those source
arrays have the same key $_REQUEST will overwrite them. $_REQUEST to
be honest, is a lame shortcut and bad idea almost on par with
register_globals.
$_REQUEST isn't dangerous - the programmer using it is.
I'm not recommending $_REQUEST.
$_PARAMETERS is an object, not an array. I suppose if treated like an
array it could behave like request - but I deeply dislike that idea
because it is a repeat of the mistake of $_REQUEST.
You're going to have a hard time selling this. Adding an object to global scope by adding yet another super global is a mess. You'd have a much easier time selling a SPL class which handles this functionality. Or, even better, write this in PHP. There wouldn't be a substantial performance improvement, and you wouldn't be forcing ideologies on other developers. If you're wondering what I mean by this, your suggestion of "setFilters" would require an interface that defines the behavior intended for filtering content. On top of this, you'd need to add getFilters, getFilter, removeFilters, removeFilter and addFilter to name a few. All of this can (and should IMO) be done within PHP.
To get a value from a get request I'd use $_PARAMETERS->get['myVar'];
To get it's filtered value I'd use $_PARAMETERS->get->filtered['myVar']
To set those filters I'd use $_PARAMETERS->get->setFilters( $filters );
As I said before, you should add a RFC entry if you want this taken seriously. The information you provided is just not enough.
Personally, I don't like this. We already have $_REQUEST which can
accommodate GET, POST, and COOKIE. I believe it should be up to
framework/API authors to implement there own methodologies behind accessing
this data. Additional functionality such as setting filters would be a part
of that as well.That said, if you're serious about the idea, a RFC would be helpful in
understanding the full extent that you're suggesting.--
Will FitchBefore writing up a full RFC I want to put out a feeler on something.
Currently we have several input parameter objects, chief among them
$_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
of them are arrays and legacy code sometimes writes to them. Locking
them as read only objects would cause a major BC break.What if instead we had an Object called $_PARAMETERS which holds the
read only copies of this data. In addition, this would be the first
superglobal object, able to perform some filtering of inputs. Basic
idea..$_PARAMETERS
->get
->post
->cookie
->headers (The client http headers)All of these would be array objects, and all would be read only and
have these methods and properties->filtered: Copy of the array according to the current set filters of
the object.
->setFilters(): Sets the filters of the input, an array with constant
values for the allowed types.And I'll stop there. The basic idea, to add a read only input hive
with some basic object functionality for filtering.
$_REQUEST does nothing of the sort, and it's use is dangerous in
RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
and $_COOKIE, in that order but the php.ini directive can change it.
Hence there's no way of knowing if $_REQUEST['password'] came from
$_COOKIE, $_POST, or $_GET, and worse, if two values in those source
arrays have the same key $_REQUEST will overwrite them. $_REQUEST to
be honest, is a lame shortcut and bad idea almost on par with
register_globals.
Given that all three of $_GET $_POST and $_COOKIE are equally suspect
from a security POV, and you shouldn't really care which way the
client delivered the value, or at least not rely on it for anything
useful, I've never understood the resistance to using $_REQUEST.
Yes, GET should be idempotent, but there are many APIs and functions
in a large app that are idempotent by nature, and having a REST that
just doesn't care how the data comes in allows the consumer of the
service to use whatever they prefer.
If your entire REST service is read-only, such as an RSS feed, why not
allow GET or POST (or, silly as it may be COOKIE) and just use
$_REQUEST.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
$_REQUEST does nothing of the sort, and it's use is dangerous in
RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
and $_COOKIE, in that order but the php.ini directive can change it.
Hence there's no way of knowing if $_REQUEST['password'] came from
$_COOKIE, $_POST, or $_GET, and worse, if two values in those source
arrays have the same key $_REQUEST will overwrite them. $_REQUEST to
be honest, is a lame shortcut and bad idea almost on par with
register_globals.Given that all three of $_GET $_POST and $_COOKIE are equally suspect
from a security POV, and you shouldn't really care which way the
client delivered the value, or at least not rely on it for anything
useful, I've never understood the resistance to using $_REQUEST.Yes, GET should be idempotent, but there are many APIs and functions
in a large app that are idempotent by nature, and having a REST that
just doesn't care how the data comes in allows the consumer of the
service to use whatever they prefer.If your entire REST service is read-only, such as an RSS feed, why not
allow GET or POST (or, silly as it may be COOKIE) and just use
$_REQUEST.
Because GET and POST are not even remotely the same thing and treating
them as completely interchangeable is a bug in the first place. It is
in fact legal to have both in the same request. Then what do you do?
The idea of having a real request object in PHP is a good one; however,
a superglobal is not it. Making it a superglobal eliminates the value
of a real request object, namely that you can encapsulate it, override
it locally, pass it around, mock it for testing, etc. in a safe fashion.
A superglobal request object is a complete waste of time.
There are a number of existing request object libraries out there
already. PECL HTTP in C, both Zend and Symfony2 have their versions,
etc. Drupal is in the process of moving to Symfony's. Any PHP-core
request object (which in general I will agree is a good thing, and
something sorely missing in the language today) should be based on one
of those, where there's already existing work done to work out the
kinks. Simply throwing $_GET onto a property of a superglobal object
does not accomplish anything useful.
--Larry Garfield
Because GET and POST are not even remotely the same thing and treating
them as completely interchangeable is a bug in the first place.
We'll have to agree to disagree here.
To me, it's just a request for some content, and in a REST API that's
read-only, I just don't care if the consumer sends their request as
GET or POST. I'll cheerfully give them what they wanted.
It is
in fact legal to have both in the same request. Then what do you do?
Option A) Don't use REQUEST if you need both
Option B) The GPC ordering is quite specific and reliable
The idea of having a real request object in PHP is a good one;
I'm not even seeing why turning the independent arrays into an object
is a Good Idea, so have chopped the rest off.
But I certainly agree that researching the PHP code "out there" is a
Good Idea to compare to the RFC to see what's missing / wrong, if one
wants to continue down the path.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Because GET and POST are not even remotely the same thing and treating
them as completely interchangeable is a bug in the first place.We'll have to agree to disagree here.
To me, it's just a request for some content, and in a REST API that's
read-only, I just don't care if the consumer sends their request as
GET or POST. I'll cheerfully give them what they wanted.
Except that per HTTP, GET and POST are completely different operations.
One is idempotent and cacheable, the other is not idempotent and not
cacheable. I very much care which someone is using.
As Will said in the other reply, there's security implications. (I
don't know who suggested that POST is more secure than GET. I certainly
didn't.) You want your login form operating over POST, not GET, in
large part for the reasons above.
--Larry Garfield
To me, it's just a request for some content, and in a REST API that's
read-only, I just don't care if the consumer sends their request as
GET or POST. I'll cheerfully give them what they wanted.
Except that per HTTP, GET and POST are completely different operations. One
is idempotent and cacheable, the other is not idempotent and not cacheable.
I very much care which someone is using.
People exploiting security would never think of
caching/replaying/modifying a POST request, that's just totally
unimaginable! It would take, like HUGE computational effort to like,
cURL it or just type it out!
er, no.
-Ronabop
To me, it's just a request for some content, and in a REST API that's
read-only, I just don't care if the consumer sends their request as
GET or POST. I'll cheerfully give them what they wanted.
Except that per HTTP, GET and POST are completely different operations. One
is idempotent and cacheable, the other is not idempotent and not cacheable.
I very much care which someone is using.People exploiting security would never think of
caching/replaying/modifying a POST request, that's just totally
unimaginable! It would take, like HUGE computational effort to like,
cURL it or just type it out!er, no.
-Ronabop
Please point out where I said that POST not a security risk. I am quite
sure I typed no such thing, so how you read such a thing I do not know.
I am genuinely curious to see how you managed to interpret anything I
said as "POST is secure because it won't be cached".
--Larry Garfield
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldlarry@garfieldtech.com
Except that per HTTP, GET and POST are completely different operations.
One
is idempotent and cacheable, the other is not idempotent and not
cacheable.
I very much care which someone is using.
People exploiting security would never think of
caching/replaying/modifying a POST request, that's just totally
unimaginable! It would take, like HUGE computational effort to like,
cURL it or just type it out!
er, no.
Please point out where I said that POST not a security risk. I am quite
sure I typed no such thing, so how you read such a thing I do not know. I
am genuinely curious to see how you managed to interpret anything I said as
"POST is secure because it won't be cached".
Well, I didn't actually say that you said any such thing. I picked up on:
"the other is not idempotent and not cacheable"
...which is obviously false, and I highlighted, in a security context,
how POSTs are cached, and should be treated with equal distrust as
GET, because both are suspect, user submitted, forms of data, subject
to exploiting.
-Ronabop
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldlarry@garfieldtech.com
Except that per HTTP, GET and POST are completely different operations.
One
is idempotent and cacheable, the other is not idempotent and not
cacheable.
I very much care which someone is using.
People exploiting security would never think of
caching/replaying/modifying a POST request, that's just totally
unimaginable! It would take, like HUGE computational effort to like,
cURL it or just type it out!
er, no.
Please point out where I said that POST not a security risk. I am quite
sure I typed no such thing, so how you read such a thing I do not know. I
am genuinely curious to see how you managed to interpret anything I said as
"POST is secure because it won't be cached".Well, I didn't actually say that you said any such thing. I picked up on:
"the other is not idempotent and not cacheable"
...which is obviously false, and I highlighted, in a security context,
how POSTs are cached, and should be treated with equal distrust as
GET, because both are suspect, user submitted, forms of data, subject
to exploiting.-Ronabop
When systems are behaving properly, POST is not cached. I was referring
to the RFC:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5
"Responses to this method are not cacheable, unless the response
includes appropriate Cache-Control or Expires header fields. However,
the 303 (See Other) response can be used to direct the user agent to
retrieve a cacheable resource."
So strictly speaking its the response to a POST that is not (by default)
cached. From a security perspective, yes, all incoming data should be
viewed as a threat until proven otherwise, regardless of what part of
the HTTP request it comes from or what superglobal PHP marshals it into
by default.
--Larry Garfield
Because GET and POST are not even remotely the same thing and treating
them as completely interchangeable is a bug in the first place.We'll have to agree to disagree here.
To me, it's just a request for some content, and in a REST API that's
read-only, I just don't care if the consumer sends their request as
GET or POST. I'll cheerfully give them what they wanted.Except that per HTTP, GET and POST are completely different operations. One
is idempotent and cacheable, the other is not idempotent and not cacheable.
I very much care which someone is using.
Correct me if I'm wrong, but you're referring to the HTTP method
used. A POST can be made to a URL that includes a query-string, but
what that means as far as interpreting the variables is undefined as
far as I know.
Because of that, I think it's a bad idea to either treat them as the
same thing, or rely on both $_POST and $_GET parameters being present.
Except that per HTTP, GET and POST are completely different operations. One
is idempotent and cacheable, the other is not idempotent and not cacheable.
I very much care which someone is using.Correct me if I'm wrong, but you're referring to the HTTP method
used. A POST can be made to a URL that includes a query-string, but
what that means as far as interpreting the variables is undefined as
far as I know.Because of that, I think it's a bad idea to either treat them as the
same thing, or rely on both $_POST and $_GET parameters being present.
The underlying problem is that HTTP has a URI query string, and a body.
In a typical GET request there is no body. In a typical POST the body
is a query string in similar format to the URI's query string, plus
possibly other stuff. In other request methods the body may be
something else entirely.
PHP's superglobals make the (wrong) assumption that the URI query string
comes from a GET query (hence $_GET) and body comes from a POST query
string ($_POST), because that matches up with the default method=""
attribute of HTML forms. That assumption is limiting and misleading,
and made worse by the existence of $_REQUEST, but is the assumption that
PHP makes.
--Larry Garfield
Except that per HTTP, GET and POST are completely different
operations. One
is idempotent and cacheable, the other is not idempotent and not
cacheable.
I very much care which someone is using.Correct me if I'm wrong, but you're referring to the HTTP method
used. A POST can be made to a URL that includes a query-string, but
what that means as far as interpreting the variables is undefined as
far as I know.Because of that, I think it's a bad idea to either treat them as the
same thing, or rely on both $_POST and $_GET parameters being
present.The underlying problem is that HTTP has a URI query string, and a
body.
In a typical GET request there is no body.
Nitpick: I think a body is explicitly NOT supposed to exist in a GET
request, and not just "typically." It's been a long time since I
read the HTTP spec though...
In a typical POST the
body
is a query string in similar format to the URI's query string, plus
possibly other stuff. In other request methods the body may be
something else entirely.PHP's superglobals make the (wrong) assumption that the URI query
string
comes from a GET query (hence $_GET) and body comes from a POST query
string ($_POST), because that matches up with the default method=""
attribute of HTML forms. That assumption is limiting and misleading,
and made worse by the existence of $_REQUEST, but is the assumption
that
PHP makes.
Unless I am very much mistaken, the HTTP spec explicitly states that
parameters in the URL with a POST request are completely kosher.
Separating those two sources in a single request, by placing the
URL-specified input as $_GET makes perfect sense to most PHP
developers, even though, strictly speaking, the are part of the POST
request.
I don't know if the HTTP spec even addresses the question of having a
URL-specified and a POST-body specified parameter of the same name.
However, given that it explicitly allows a URL with
?foo=bar&foo=12&foo=whatever, I can't see how it would ban the
duplicity of POST data and GET data having the same parameter name,
once it allows URL-specified and POST-body specified parameters.
I have certainly always enjoyed PHP's extension of the spec to create
an array for multiple params ending in []. Trying to do the same sort
of thing in old-school ASP made me tear my hair out...
I like the way PHP handles $_GET $_POST and $_REQUEST, and you don't.
Neither is "right" or "wrong"
Sometimes I find $_REQUEST useful, sometimes I don't.
I have presented at least one use case where I do not care where the
input comes from, because the operations are all idempotent, and
nothing in the spec says POST has to be NON-idempotent.
Another use-case, back before CSS let you change presentation of
buttons and links, and javascript was just a nightmare of
incompatibilities in even the most simple scripts, was a case where
the look and feel dictated links (GET) on one page, and buttons (POST)
on the other page. I simply used $_REQUEST in the processing page,
which was just a read-only filter to idempotent requests.
I believe one was a search FORM that was POST, and the other was just
pagination with filters.
Perhaps, in retrospect, the FORM should have used method="GET" (the
preferred capitalization in those days). But it may have set some
session-preferences, and therefore not been strictly idempotent, while
the GET did not set preferences... It's been a long time...
At any rate, I still contend that when the server just doesn't care
what method of request comes in, because they are all idempotent,
there is no need to insist that GET be used if the consumer of the
service finds POST more convenient.
GET must be idempotent. The converse is not true. An idempotent
request does not HAVE to be a GET.
In other words, POST is not required to be NON-idempotent, even if GET
cannot be NON-idempotent.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
Except that per HTTP, GET and POST are completely different
operations.
One is idempotent and cacheable, the other is not idempotent and not
cacheable. I very much care which someone is using.
If all my operations are idempotent, regardless of the request method,
I can and will cache the POST operations, because I know I can do so.
In other words: The HTTP spec specifically requires GET to be
idempotent, and that implies it is cacheable.
Nowhere in the HTTP spec can I find a REQUIREMENT for POST to not be
idempotent, or to NOT be cached if it happens to BE idempotent.
If I'm wrong please cite your reference.
As Will said in the other reply, there's security implications. (I
don't know who suggested that POST is more secure than GET. I
certainly
didn't.)
I know you wouldn't say that.
Only total newbies think POST is "more secure" because they just don't
understand how they work.
You want your login form operating over POST, not GET, in
large part for the reasons above.
Obviously login MUST be POST. It's not idempotent.
Authentication to receive the content would also have to be POST, as
it's not idempotent.
But there is no reason to REQUIRE idempotent requests to be GET, and
no specification that I can find that states that it is.
The only requirement is that NON-idempotent must NOT be GET.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
$_REQUEST does nothing of the sort, and it's use is dangerous in
RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
and $_COOKIE, in that order but the php.ini directive can change it.
Hence there's no way of knowing if $_REQUEST['password'] came from
$_COOKIE, $_POST, or $_GET, and worse, if two values in those source
arrays have the same key $_REQUEST will overwrite them. $_REQUEST to
be honest, is a lame shortcut and bad idea almost on par with
register_globals.Given that all three of $_GET $_POST and $_COOKIE are equally suspect
from a security POV, and you shouldn't really care which way the
client delivered the value, or at least not rely on it for anything
useful, I've never understood the resistance to using $_REQUEST.Yes, GET should be idempotent, but there are many APIs and functions
in a large app that are idempotent by nature, and having a REST that
just doesn't care how the data comes in allows the consumer of the
service to use whatever they prefer.If your entire REST service is read-only, such as an RSS feed, why not
allow GET or POST (or, silly as it may be COOKIE) and just use
$_REQUEST.Because GET and POST are not even remotely the same thing and treating
them as completely interchangeable is a bug in the first place. It is
in fact legal to have both in the same request. Then what do you do?
The same thing that is done with $_REQUEST and virtually any other global parameter-based framework. You set your data priority. If you need to access them separately, then you can do that. What Richard said wasn't that they are identical, rather they should be treated with equal security measures. The idea that POST is more secure than GET is ridiculous. That said, you should care about which section of the request header you submit the data (e.g. you obviously don't want your login form to submit via GET).
The idea of having a real request object in PHP is a good one; however,
a superglobal is not it. Making it a superglobal eliminates the value
of a real request object, namely that you can encapsulate it, override
it locally, pass it around, mock it for testing, etc. in a safe fashion.
A superglobal request object is a complete waste of time.There are a number of existing request object libraries out there
already. PECL HTTP in C, both Zend and Symfony2 have their versions,
etc. Drupal is in the process of moving to Symfony's. Any PHP-core
request object (which in general I will agree is a good thing, and
something sorely missing in the language today) should be based on one
of those, where there's already existing work done to work out the
kinks. Simply throwing $_GET onto a property of a superglobal object
does not accomplish anything useful.
As you noted, every framework has their own version of request/response objects. This is the job of a framework and not the core language.
--Larry Garfield
Before writing up a full RFC I want to put out a feeler on something.
Currently we have several input parameter objects, chief among them
$_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
of them are arrays and legacy code sometimes writes to them. Locking
them as read only objects would cause a major BC break.What if instead we had an Object called $_PARAMETERS which holds the
read only copies of this data. In addition, this would be the first
superglobal object, able to perform some filtering of inputs. Basic
idea..
What's the benefit over filter_input()?
johannes
Before writing up a full RFC I want to put out a feeler on something.
Currently we have several input parameter objects, chief among them
$_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
of them are arrays and legacy code sometimes writes to them. Locking
them as read only objects would cause a major BC break.
Why would you want to set them read-only?
I agree that they should represent the input parameters, but there are times
where modificating them is very useful.
For instance, a framework code could be modifying $_GET on index.php to
strip magic quotes before passing it down to another module.
Even better, that code would work even for modules written before
supporting
that configuration.
If the module had used directly such $_PARAMETERS, it would get wrong
results.
I guess we will start seeing the opposite behavior with 5.4, though:
Code doing
addslashes() on input parameters before running code which expected magic
quotes (maybe at auto_prepend_file, even). But still, it's good to have
such
ability even if it's something to be avoided.
Yes, I'm agree with Will Fitch.
Handling this problem with PHP is a good idea and beneficial to programmer.
2012/2/23 Ángel González keisial@gmail.com
Before writing up a full RFC I want to put out a feeler on something.
Currently we have several input parameter objects, chief among them
$_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
of them are arrays and legacy code sometimes writes to them. Locking
them as read only objects would cause a major BC break.Why would you want to set them read-only?
I agree that they should represent the input parameters, but there are
times
where modificating them is very useful.
For instance, a framework code could be modifying $_GET on index.php to
strip magic quotes before passing it down to another module.
Even better, that code would work even for modules written before
supporting
that configuration.
If the module had used directly such $_PARAMETERS, it would get wrong
results.I guess we will start seeing the opposite behavior with 5.4, though:
Code doing
addslashes()on input parameters before running code which expected magic
quotes (maybe at auto_prepend_file, even). But still, it's good to have
such
ability even if it's something to be avoided.
Before writing up a full RFC I want to put out a feeler on something.
Currently we have several input parameter objects, chief among them
$_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
of them are arrays and legacy code sometimes writes to them. Locking
them as read only objects would cause a major BC break.What if instead we had an Object called $_PARAMETERS which holds the
read only copies of this data. In addition, this would be the first
superglobal object, able to perform some filtering of inputs. Basic
idea..$_PARAMETERS
->get
->post
->cookie
->headers (The client http headers)All of these would be array objects, and all would be read only and
have these methods and properties->filtered: Copy of the array according to the current set filters of
the object.
->setFilters(): Sets the filters of the input, an array with constant
values for the allowed types.And I'll stop there. The basic idea, to add a read only input hive
with some basic object functionality for filtering.
I can see how you would want this, but it seems to me that you can
code this easily enough in PHP, with a singleton class with private
read-only properties that initialize to the various $_XXX values, and
a filter method that employs PHP FILTER.
Personally, I think introducing a whole new feature to be maintained
and documented to save defining a couple simple classes and a page of
code is not a "win".
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE