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=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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
