Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, February 24, 2012 4:40 pm, Larry Garfield wrote: On 2/24/12 4:34 PM, Richard Lynch wrote: On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote: On 2/24/12 3:28 PM, Richard Lynch wrote: 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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, February 24, 2012 4:48 pm, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield la...@garfieldtech.com wrote: 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! You missed the totally newbie way, or at least a way to demonstrate the issue to somebody who simply doesn't understand the issue: Save the HTML form to your hard drive. Edit it in Notepad (et al) to make up whatever value=xyz you want. Open it in your browser using Open File... and pick the file. Submit the FORM. I had to do this several times for non-technical bosses or students who simply refused to believe that it was TRIVIAL to forge POST requests... Once they saw it in action, the light bulb goes on and you can say: I can also script this to repeat the same thing a million times with form-letter substitution, and then they understand it *is* trivial. Maybe I just had dense bosses/students, or I was bad at explaining the idea, but it worked for me... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Mon, Feb 27, 2012 at 6:17 PM, Richard Lynch c...@l-i-e.com wrote: On Fri, February 24, 2012 4:48 pm, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield la...@garfieldtech.com wrote: 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! You missed the totally newbie way, or at least a way to demonstrate the issue to somebody who simply doesn't understand the issue: Save the HTML form to your hard drive. Edit it in Notepad (et al) to make up whatever value=xyz you want. Open it in your browser using Open File... and pick the file. Submit the FORM. I had to do this several times for non-technical bosses or students who simply refused to believe that it was TRIVIAL to forge POST requests... Once they saw it in action, the light bulb goes on and you can say: I can also script this to repeat the same thing a million times with form-letter substitution, and then they understand it *is* trivial. Maybe I just had dense bosses/students, or I was bad at explaining the idea, but it worked for me... changing the method in curl is even easier. you both missed the fact that Larry is aware of the fact that POST is forge-able. there are cases when you can improve your security model (even by a little bit) if you don't allow the method to be interchangeable. for example: if I have an XSS vulnerability on bugs.php.net, it is much easier for me to trick the devs clicking on the link if the said vuln is exploitable through GET. if it can only be exploited through POST, I have to set up a page somewhere with a POST form, pointing to the vulnerable url, and ask the said devs to visit that url and submit the form (or have javascript enabled, so that I can submit if for them). exploiting the reflected vulnerabilities is much easier if you can do it through GET. ps: if you don't know what did Larry mean by the Idempotent method, see http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1 -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, February 24, 2012 5:15 pm, Larry Garfield wrote: On 2/24/12 4:55 PM, Jeremiah Dodds wrote: 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=barfoo=12foo=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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Wed, February 22, 2012 8:57 am, Michael Morris wrote: 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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Wed, February 22, 2012 9:10 am, Michael Morris wrote: $_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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 3:28 PM, Richard Lynch wrote: On Wed, February 22, 2012 9:10 am, Michael Morris wrote: $_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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote: On 2/24/12 3:28 PM, Richard Lynch wrote: 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-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Friday, February 24, 2012 at 5:16 PM, Larry Garfield wrote: On 2/24/12 3:28 PM, Richard Lynch wrote: On Wed, February 22, 2012 9:10 am, Michael Morris wrote: $_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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 4:34 PM, Richard Lynch wrote: On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote: On 2/24/12 3:28 PM, Richard Lynch wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfield la...@garfieldtech.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 4:48 PM, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldla...@garfieldtech.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, Feb 24, 2012 at 5:40 PM, Larry Garfield la...@garfieldtech.com wrote: On 2/24/12 4:34 PM, Richard Lynch wrote: On Fri, February 24, 2012 4:16 pm, Larry Garfield wrote: On 2/24/12 3:28 PM, Richard Lynch wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfield la...@garfieldtech.com wrote: On 2/24/12 4:48 PM, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldla...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 5:04 PM, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:54 PM, Larry Garfieldla...@garfieldtech.com wrote: On 2/24/12 4:48 PM, Ronald Chmara wrote: On Fri, Feb 24, 2012 at 2:40 PM, Larry Garfieldla...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 2/24/12 4:55 PM, Jeremiah Dodds wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] $_PARAMETERS Super Global Object
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
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 On Wednesday, February 22, 2012 at 9:57 AM, Michael Morris wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
$_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 ); On Wed, Feb 22, 2012 at 10:03 AM, Will Fitch will.fi...@gmail.com wrote: 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 On Wednesday, February 22, 2012 at 9:57 AM, Michael Morris wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Wednesday, February 22, 2012 at 10:10 AM, Michael Morris wrote: $_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. On Wed, Feb 22, 2012 at 10:03 AM, Will Fitch will.fi...@gmail.com (mailto:will.fi...@gmail.com) wrote: 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 On Wednesday, February 22, 2012 at 9:57 AM, Michael Morris wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On Wed, 2012-02-22 at 09:57 -0500, Michael Morris wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
On 22/02/12 15:57, Michael Morris wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $_PARAMETERS Super Global Object
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 keis...@gmail.com On 22/02/12 15:57, Michael Morris wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
