On $_GET and $_POST

The PHP manual has the following to say about the notorious superglobals, $_GET and $_POST:

$_GET
An associative array of variables passed to the current script via the HTTP GET method.
Source: php.net

$_POST
An associative array of variables passed to the current script via the HTTP POST method.
Source: php.net

Let’s see how a typical PHP application works, shall we?

When a PHP script is invoked by a web server, it is as the result of a HTTP request. A HTTP request has a target URI and that URI consists of different parts. One of these parts is the query. That is the part that comes after any question mark. Or more formally:

  <scheme>://<authority><path>?<query>
  absoluteURI   = scheme ":" ( hier_part | opaque_part )
  hier_part     = ( net_path | abs_path ) [ "?" query ]
  net_path      = "//" authority [ abs_path ]
  abs_path      = "/"  path_segments

Source: rfc 2396

As the PHP process starts up, the query gets parsed into an associative array. And for some reason, somebody decided on the unfortunate $_GET, because it’s what you use for GET requests – right?

Wrong!

All HTTP requests – GET, POST and the lesser known ones – have a URI. Since they all have a URI, they also have a query, and thus the $_GET array is available for all of them. In other words, a POST request also has $_GET parameters. No wonder people get tripped up about HTTP and REST. But it gets worse yet.

In addition to a URI, some HTTP requests may contain a message body; Not all requests (A GET may not, for example) – but some. The most common example of request that contains a message body is the POST type. Enter the $_POST variable. Like its cousin $_GET, this is populated at startup, but with the message body parsed as application/x-www-form-urlencoded. Unlike $_GET this isn’t part of the HTTP specification, but specifically the kind of encoding that browsers will submit HTML <form> in. In practise, this is a fairly safe bet, because browsers only are capable of submitting forms as GET and POST, but technically there’s nothing stopping someone from sending a PUT type request with a form-encoded message-body.

Then there is $_FILES, which is similar to $_POST, in that it is an interpretation of the message body, but this time according to rfc 1867, which by the way is the recommended encoding for POST requests. Yay!

So now that all the specifications have been summed up, here is my gripe with PHP.

The problem with $_GET and $_POST is that a lot of people assume – understandably, but wrongly – that $_GET is somehow tied to GET requests, and that $_POST correspondingly is what you use for POST requests. But that’s not the case. A POST request can well have relevant data in $_GET. Or in $_FILES. And form-encoding is not restricted to POST requests – Thus $_POST may contain relevant data for a PUT request.

The current names are confusing and obscures the intention of HTTP; More descriptive names would have been $_QUERY instead of $_GET and $_FORM* instead of $_POST (Which would match the etymology of the name $_FILES).

* As has been pointed out in the comments, perhaps $_FORM isn’t the best of names either.

If it seems like a hassle to change that, allow me to remind that something similar was done a couple of years ago and that didn’t seem to bother anybody back then. But for starters, a clarification of the documentation would be a step in the right direction.

And I won’t even comment on the nastiness of $_REQUEST.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Rory

    I can see what you’re getting at with $_QUERY and $_FORM but if you define your form as <form method="get"> your form data will be in $_QUERY not $_FORM which is possibly just as confusing for those who don’t understand the difference. I suspect the method attribute on forms is where $_GET and $_POST came from.

  • Maarten

    The biggest problem on this subject is that a lot of people do not understand the semantic difference between the HTTP GET and POST methods, and this change would certainly not help.

    By not explaining the difference in idempotence (this keyword should have made it into your blog post) and by renaming $_POST into $_FORM, its actually not clear if you for yourself understand this difference in semantics…

  • Troels Knak-Nielsen

    Good point about <form method="..">, Rory. That probably explains the origin of those names, but it’s hardly a justification. In HTML there is an implicit encoding associated with the HTTP method, but it’s possible to override the defaults with the enctype attribute. I can see that $_FORM might be slightly misleading as well, but at least it doesn’t conflate HTTP method with message encoding. A more precise name could have been $_FORM_ENCODED_MESSAGE_BODY, but that wouldn’t be very practical. Perhaps $_BODY could do. But considering that most forms are submitted through POST, I consider the name $_FORM much less problematic than $_POST.

  • http://www.tonymarston.net Tony Marston

    Your statement that a POST request has $_GET parameters and a GET request has $_POST parameters is totally wrong. I have just tried generating both types of request on my local copy of Apache/PHP and I have confirmed that a POST provides only $_POST and a GET provides only $_GET. However, both sets of data are always available in $_REQUEST.

  • Mathic

    How about:

    <form method="post"; action="abc.php?var=value1">
    <input type="hidden" name="var" value="value2" >

    Currently both will populate:

    You will get a nice $_POST["var"] != $_GET["var"]

    If, on the form (for search forms GET is supposed to be used as it doesn’t/shouldn’t change anything on the server), method="get" then in your proposed scheme the $_FORM will populate with the value2 and the $_REQUEST with value2.
    However, won’t browsers interpret it differently and do: abc.php?var=value1&var=value2 (if you are lucky)?

  • Troels Knak-Nielsen

    Hi Tony.

    Your statement that (…) a GET request has $_POST parameters is totally wrong.

    I think you have misread me there; I specifically made the point that a GET request does not have a message-body, and thus no $_POST. So it should be no surprise that your test confirms this.

    Your statement that POST request has $_GET parameters (…) is totally wrong. I have (…) confirmed that a POST provides only $_POST.

    I think your test may be flawed somehow. If you send a POST request to a PHP script, you will get the query parsed into $_GET, and the message-body parsed into $_POST.

    You can observe that this is the case, with the following test:

    <?php
    var_dump(array("_GET" => $_GET, "_POST" => $_POST));
    ?>
    <form method="post" action="?foo=getparam">
    <input type="text" name="foo" value="postparam" />
    <input type="submit" />
    </form>
    

    Which yields the following output:

    array(2) {
      ["_GET"]=>
      array(1) {
        ["foo"]=>
        string(8) "getparam"
      }
      ["_POST"]=>
      array(1) {
        ["foo"]=>
        string(9) "postparam"
      }
    }
    
  • http://www.tonymarston.net Tony Marston

    The reason you are getting both $_GET and $_POST data from a POST is that your ‘action=”foo”‘ attribute in the FORM area contains a query instead of just a script name. This is non-standard, therefore if you use a FORM area with method=”POST” in the standard way you will only see data in the $_POST array.

  • Troels Knak-Nielsen

    Which standard are you referring to?

    The specification of a <form> says that the action contains a URI. A URI consists – among other things – of a query. So there is nothing non-standard about providing a URI with a query. The only thing non-standard, is that browsers allow you to put a partial URI in the action attribute, which is then resolved to a full URI before submitting. But that’s rather irrelevant here.

    That all aside, forms are not the only way to send a HTTP POST request – just the most common one. Every HTTP request has a Request-URI – The specification is quite clear about this.

  • http://www.tonymarston.net Tony Marston

    I do not mean a documented standard that says the action attribute in the FORM area of an HTML document CANNOT contain additional query arguments, I mean that I have never seen any documentation which says that it CAN. For example, there is no reference to this “feature” in http://www.php.net/manual/en/tutorial.forms.php

    As this feature is not documented and therefore rarely used I consider it to be non-standard.

  • Troels Knak-Nielsen

    Yes, that was my point actually – That the PHP documentation is inadequate.

    The case that you call it non-standard should be a clear warning sign that something is amiss. If PHP and the HTTP specification disagrees about HTTP, then it’s obviously PHP that is wrong.

  • http://www.tonymarston.net Tony Marston

    There is nothing in the HTTP specification which identifies what is returned where because of a GET or a POST.

    The HTML specification at http://www.w3.org/TR/html401/interact/forms.html#h-17.3 simply states that the ‘action’ attribute contains a URI and does not identify that the URI may contain query arguments, or whether these arguments should be appended to the GET or POST data.

    Before you start saying that this is a PHP problem you should point out the documentation which says what SHOULD happen in these circumstances, then verify that other languages such as Java, Perl, Ruby, et cetera, behave in the expected manner.

    It is not normal behaviour to include query arguments in the ‘action’ attribute of an HTML FORM element, therefore your conclusion that PHP “does it wrong” is eroneous.

  • Anonymous

    A URI may include a querystring, and as such is a valid value in a form’s action attribute. (See Section 3 at http://www.ietf.org/rfc/rfc2396.txt) . I’ve been doing this for years!

    As for a better naming-scheme for PHP’s superglobals, I would like to see something like $_HTTP that encodes the entire HTTP request! Perhaps this is what should be in $_REQUEST… as it currently stands, we have to to use $_GET, $_POST, $_REQUEST, $_SERVER, $_SESSION all as separate variables, when this data already exists and (for the most part) is just part of a standard HTTP request (excluding some parts of $_SERVER)!

  • Troels Knak-Nielsen

    The HTML specification at http://www.w3.org/TR/html401/interact/forms.html#h-17.3 simply states that the ‘action’ attribute contains a URI and does not identify that the URI may contain query arguments (…)

    The same text refers to the definition of a URI. No need to restate the specifics when there is a reference to it.

    (…)you should point out the documentation which says what SHOULD happen in these circumstances(…)

    See http://www.w3.org/TR/html401/interact/forms.html#submit-format and the already referred rfc 2616.

    It is not normal behaviour to include query arguments in the ‘action’ attribute of an HTML FORM element (…)

    The specification allows it. The technology implements it. I don’t see how there could be any doubt?

    The fact that you weren’t aware of a behaviour that is defined in the specification doesn’t mean that the specification is wrong. That is, unless you define HTTP differently than the canonical specification – but then we don’t mean the same thing when we use the word HTTP, and then we won’t be getting far with this discussion. You can make the claim that you don’t like how the HTTP protocol is defined, but you can’t claim that it’s wrong.

  • http://www.tonymarston.net Tony Marston

    The HTML specification at http://www.w3.org/TR/html401/interact/forms.html#submit-format does not state what is supposed to happen if the ‘action’ attribute contains query arguments. It does not state whether they should be appended to either the GET or POST data. It makes no mention of the query arguments at all.

    It is wrong of you to state that the specification allows it, therefore PHP is wrong because it does not do what you expect for the simple reason that the specification makes no mention of this “feature” at all. It does not state what should happen in these circumstances, therefore whatever is done cannot be wrong. Your expectations are therefore wrong.

    How do other languages cope with this “feature”? Are they also wrong?

  • xman

    Of course you can have a query string on a POST. Why is this a problem? Why do you think that PHP has the variable_order control value? It defines in which order possibly conflicting values get stored in $_REQUEST.

    I don’t see why any of you have a problem with all this – the query string stuff goes in _GET, the POST body goes in _POST, the FILES in FILES and the cookies in _COOKIE. Where is the problem? If you understand how the protocol works it makes perfect sense and, indeed, the PHP design is rather good.

  • RandallSquared

    Tony: This is definitely a feature, rather than a bug. I use method=”POST” almost exclusively for actual forms, but since I typically also use action=””, whatever GET switches applied to the request that generated the form continue to apply, and that’s important for my apps. These are different channels, and you can use them separately or together.

  • Anonymous

    There is no reason to have a form action like that. Just because it allows it doesn’t mean it would EVER be used by a competent developer, and if there is a use for this that a hidden input type can’t take care of then I would be open to hear it. Until you can come up with a valid reason to have get variables with post variables (especially considering the limitations on get variables), your whole post is really pointless.

  • till

    Sorry, but what? There’s `GET` and `POST` — what on earth is not obvious about them? Maybe because it requires people make the connection between `method=”post”` (or `”get”`) and a variable name in order to collect data from a form?

    I see your notion and I agree that there’s nothing wrong with simple things, but why don’t you keep it in userland and write a library to do it for you instead of polluting a language with a feature for people who don’t want to learn.

    As others have pointed out, I believe that aside from the “benefit”, `$_FORM` is complicated, e.g. where do you propose is the “magic” which puts the data into `$_FORM`? Also, a HTTP request is a HTTP request — how do you tag it to contain form data?

    I suggest that everyone who doesn’t understand it yet, should read the Wikipedia-Entry on REST. It’ll also dip into HTTP and one will realize how simple the protocol really is. And that’s the beauty of it!

    Also, RE: `$_REQUEST`. It doesn’t just include `$_POST` and `$_GET`, but also `$_COOKIE`. Now digging a little deeper, you will realize that the order of which the contents are “written into” `$_REQUEST` (GPC usually) may vary and is configurable. So as you can see — if you know what it does, it’s not as nasty as you may think.

    Sitepoint is usually a better source for PHP-related tutorials and opinion. Please don’t start dipping into the DevShed market. ;-)

  • Troels Knak-Nielsen

    We’re mixing two things together here: There is a specification for HTML and there is one for HTTP. We can argue about the exact phrasing of the HTML specification, but I see no reasonable way that you could claim that a HTTP POST request can’t have a query part in its URI. That’s very clearly defined in rfc 2616.

    Now regarding HTML: PHP doesn’t interpret HTML – the browser does that. The only thing PHP should be concerned with is the HTTP request that comes back from the browser, but even if we were to discuss how the action attribute of <form> is defined, I will maintain that you are misreading the specs. And if there was ever the slightest doubt about it, it should be clear from the fact that all browsers work the same in this respect.

  • http://www.tonymarston.net Tony Marston

    I never said that an HTTP POST request can’t have a query part in its URI. The HTTP specification does not say that it can just as it does not say that it cannot.

    When dealing with the FORM area in an HTML document the only relevant specification is http://www.w3.org/TR/html401/interact/forms.html#submit-format which makes absolutely no mention of any query arguments which may be contained within the URI. It does not identify that they may exist and it does not identify whether they are to be appended to POST or GET data.

    Unless you can point to the place in the HTML documentation which states that query arguments in the ‘action’ attribute should be appended to the GET/POST data (depending on the ‘method’ atribute) then what you are referring to is an undocumented feature, in which case there is no such thing as “wrong” behaviour.

    I am sure that if the browser sent everything back in the POST area then PHP would present it all in the $_POST array. If PHP separates it then in must be sent as separated from the browser.

    You still haven’t identified what other languages do in this situation.

  • The Big Lebowski

    The problem with $_GET and $_POST is that a lot of people assume – understandably, but wrongly – that $_GET is somehow tied to GET requests, and that $_POST correspondingly is what you use for POST requests. But that’s not the case. A POST request can well have relevant data in $_GET. Or in $_FILES. And form-encoding is not restricted to POST requests – Thus $_POST may contain relevant data for a PUT request.

    Nobody ever said $_GET and $_POST (or any of the other superglobals) were mutually exclusive. While this might be confusing for some, I have to say that I never fell into that trap and this is the first time I’ve even thought about it.

  • bill

    You still haven’t identified what other languages do in this situation.

    It’s definitely possible. ASP.NET pages with query strings do postbacks to the same page with the same querystring. I remember that I once used classic ASP to do the same thing: The data from the query string went into Request.QueryString, and the data from the POST went into Request.Form.

  • sigh…

    That was the worst conversation I have read all week. Let me summarize what I got out of it: “Don’t use the same variable name in both the query portion of the action and as a form variable, because, if you’re not careful, you may end up having the above exchange with someone”

  • edthered

    I’m gonna have to agree with others, this article confuses me a lot more than the php manual on $_GET and $_POST ever did. I just figured it was common knowledge that $_GET was query string and $_POST was form and that they aren’t mutually exclusive. (aside from no $_POST on an action=get form, but then you’re not posting anything so why would there be?)
    -
    As for bad coding on using a query string in action= with a POSTed form? Where do you get that? I wouldn’t put the same variables in both, but that would just be silly anyway. (unless of course if you’re cURL’ing to a script where you don’t know which it’s looking at, $_GET or $_POST, and there’s no sensitive data in the query string)

  • Tim

    @Troels

    I noticed this behaviour about 10 years ago and brought it up with the PHP developers, and they assured me it wasn’t a bug. My gripe was exactly what you stated, my query string variables on the form action ended up in the $_GET array and the rest of the data inside the form ended up in the $_POST array. The documentation implies that it should have all ended up in the $_POST array, not that $_GET is simply a break down of the query part of a URI.

    The worst part was, all the developers would say is “it’s supposed to work that way” and left me on my own to figure out why and never offered an official explaination or clarification of the documentation. Back then at least, developer education was the last thing they were concerned about.

  • patrick

    Hi,

    i think PHP let you decide to use the _SUPERGLOBALS_ or implement your own HTTP Request/Response Implementation, e.g. via php’s header function.

  • http://www.tonymarston.net Tony Marston

    @ Tim

    > “it’s supposed to work that way”

    This is a perfectly valid response from the PHP developers. The contents of the FORM area with a method=”POST” goes into the $_POST array, while everything else (which includes the ‘action’ attribute) goes into the $_GET array. There is nothing in the HTML spec which says otherwise.

    If you don’t like this behaviour then the answer is simple – don’t put arguments in the query string of the ‘action’ attribute, put them in the FORM area instead (like all sensible programmers).

  • http://shiflett.org/ shiflett

    I never said that an HTTP POST request can’t have a query part in its URI. The HTTP specification does not say that it can just as it does not say that it cannot.

    Tony, it’s clear that you’re not well-versed in this subject, so you’re not doing anyone any favors, including yourself.

    Refer to section 5.1 of RFC 2616. This section describes the format of the request line in an HTTP request:

    Request-Line = Method SP Request-URI SP HTTP-Version CRLF

    Note the Request-URI part. Its definition is very precise. This is the nature of RFCs.

    Also note that this is the most complete and authoritative specification for HTTP, but there are many parts of HTTP (like cookies) that are defined elsewhere. This is why some people have written books about HTTP.

    Hope this helps.

  • http://www.tonymarston.net Tony Marston

    @ shiflett

    What the HTTP specification says about URIs is irrelevant. It is the HTML specification which identifies what is supposed to happen with the FORM area in an HTML document when method=POST. If you bother to read it you will find that it says NOTHING about any arguments in the query string of the action attibute. It does not say that they should be appended to the FORM data, or does it say that they should appear separately. If it does identify what the RIGHT behaviour is then nothing can be classed as the WRONG behaviour.

  • http://shiflett.org/ shiflett

    What the HTTP specification says about URIs is irrelevant.

    I was trying to be gentle, but the truth is that every competent developer knows what a URI is. I only reference the precision of specifications to suggest that it is not ambiguous and is something you can look up if you’re unsure.

    Whether you think the standards that make up the Web are irrelevant is irrelevant.

    As an aside, is this the quality of discourse here on SitePoint these days, or is this an anomaly?

  • http://www.tonymarston.net Tony Marston

    @ shiflett

    You are still missing the point. What happens to the contents of the FORM area in an HTML document is determined in the HTML specification, not the HTTP specification. What may or may not be contained in a URI is irrelevant unless the HTML specification identifies what is to be done with each component of a URI. The HTML specification does not identify the RIGHT action to be taken with query arguments in the ‘action’ attribute of the FORM area, so it is incorrect to say that PHP gets it wrong.

    I repeat, the HTTP specification has NOTHING to do with the FORM area in HTML documents.

  • http://www.tonymarston.net Tony Marston

    @ Anonymous

    Where does the HTTP spec state that the query arguments within the ‘action’ attribute are included with the data elements within the FORM area when the method is POST?

  • Laurent

    Why are you guys saying that having query parameters in the action of the form when using POST is uncommon.
    I’ve seen a lot of AJAX code doing just that.

    The action of the form would often look like action=”script.php?c=class&m=method”. The form is submitted thru an XmlHttpRequest and the request will have the action of the form as URI and the content of the form being POSTed, I see nothing wrong with that, actually I find it a rather elegant solution.
    You end up having to look in $_GET to get the class/method to run, and in $_POST for the payload.

  • cringer

    This is an odd gripe. PHP surely has bigger problems. I don’t like that PHP is one big mess of loosely organized functions with an inconsistent naming scheme. $_POST, $_GET, $_REQUEST etc. never gave me a bit of trouble. Trying to remember if there’s an underscore in one of hundreds of function names is a common hassle. Sorry if I missed the point.

  • Troels Knak-Nielsen

    cringer:

    This is an odd gripe. PHP surely has bigger problems.

    Surely that shouldn’t be an argument to not fix things?

    xman:

    Where is the problem? If you understand how the protocol works it makes perfect sense and, indeed, the PHP design is rather good.

    APIs – including those that the core language exposes – affect the programs that interact with them, just like language affects the way that we think and act. If the core API conflates two related, but separate, subjects, then a lot of people will get them mixed up. That leads to design mistakes.

  • bmbsa

    $_REQUEST also includes $_SESSION

  • mario

    I’m not sure about the intended audience, but as introduction to form submissions this is probably a good article.

    Some recommendations however seem troublesome. There is nothing wrong with using $_REQUEST[]. I would go so far and say it should be preferred over the individual input arrays. If you ever want to add AJAX/RPC methods, it’s less troublesome if the application logic isn’t pesky about the input array – without any need.
    Unless you give them quirky or conflicting names, input variables shouldn’t be handled differently based upon if they arrived in a GET list or POST structure.

    I guess, the note stems from the misguided assumption, that for example the $_POST array was somehow “safer”. This thinking is widespread among some users who don’t have any graphical tool handy that could manually construct HTTP requests (headers, body -> GET and POST params). This note sounded a little like that:

    [...] In practise, this is a fairly safe bet, because browsers only are capable of submitting forms as GET and POST, but technically there’s nothing stopping someone from sending a PUT type request with a form-encoded message-body.

    I’ve seen lots of amateur code that adheres to differentiating $_GET and $_POST, yet ignorizes basic input sanitizing. And in my opinion, that’s often more important than the actual input source. Input vars are input vars, and should be treated alike – hence I wouldn’t spend time with the grouping nonsense under the assumption it might enhance security.

    A more legitimate way to look at GET and POST requests are HTTP semantics. POST should be used whenever stuff might get added or modified server-side (in the database). GET forms however should be used when there is no lasting state change on the server – if data is only read but not modified. (Though, that’s in no way a binding rule.)
    The PHP input arrays exist regardless of the request method however, and clinging on _GET and _POST isn’t necessary nor senseful.

  • digital-ether

    The PHP being discussed here is in a web server environment, which would never receive

    FTP submits. So you can’t really say it has anything to do with a HTML Form

    Specifications, it is just the HTTP Specs, and PHP running on a HTTP Server’s

    representation of the HTTP Request. You could for instance have CLI PHP listening on the

    FTP port and receive an FTP GET from a HTML Form, that has nothing to do with the HTML

    specifications, just FTP specs and PHP in CLI mode’s representation of that FTP GET

    Request. HTML specs just represent a convention for creating a HTTP Request from a HTML

    enabled HTTP Client – in this context.

    I believe the current implementation in PHP follows the conventions of HTML Forms more

    then it does HTTP – probably because the PHP team realized that web development is more

    HTML centric, then HTTP centric (Just ask a web developer which they understand better,

    HTML or HTTP). That is why it becomes a bit ambiguous when you want to use features of

    HTTP that don’t correspond directly with an HTML Form property in PHP’s representation of

    the HTTP Request.

    Would be nice if PHP had an object oriented representation of the HTTP request natively.

    For instance, if you want to check what type of HTTP Request you just received you have

    to use $_SERVER['REQUEST_METHOD']. To get Content-Type you do $_SERVER['CONTENT_TYPE']

    and other headers are also in $_SERVER prefixed with “HTTP_” etc.

    See this code for an example of getting each element of PHP together. The HTTP Request is

    represented in a way that is not easy to understand.
    http://www.fijiwebdesign.com/fiji-web-design-blog/acess-

    the-http-request-headers-and-body-via-php.html.

    It would be nicer if you had something like.

    $Request = new HTTPRequestSingleton();
    $Request->method();

    And retrieving parameters could be:

    $Request->getParam(‘param_name’);

    Getting the Content-Type:

    $Request->getType();

    Getting a URI query parameter.

    $Request->getURI()->getParam(‘param_name’);

    This makes more sense then populating the $_GET with URI query parameters when you have a

    HTTP Request of method GET.

    Seems more simple then the current implementation.

    I believe you can get something similar with a PECL extension, but a native

    implementation would be nice.

  • http://www.siradrian.com/ SirAdrian

    It makes perfect sense to me…

    Take the example action “/file.php?do=view” with data posted to it. You are POSTing data to the server, but you are still requesting /file.php?do=view from the server. The ‘do’ => ‘view’ part is a request, not a data submission. It could also dictate what the server response is after the data is posted.

    I see it most commonly used for do/action blocks of code. Honestly I prefer rewritten URLs for this, but either way works and to me have the same meaning.

  • webaddictz

    Hi Troels,

    Good article! I agree with you on the poorly chosen naming of the get and post superglobals. My own request object knows a query and body instead of get and post, for this very reason.

    I wouldn’t go into debate with Tony Marston any more, it should be obvious to any (web)developer that a URI is supposed to denote a resource, and that it might have a query string in it. It should also be obvious that the URL is seperate from the request method.

    @digital-ether:
    > Would be nice if PHP had an object oriented representation of the HTTP request natively.

    Unfortunately, there is no “native” representation of the request, but there is a PECL extension you can install which implements an Object Oriented representation of both the HTTP request and the HTTP response: http://www.php.net/manual/en/intro.http.php

  • http://www.tonymarston.net Tony Marston

    @ webaddictz

    > I wouldn’t go into debate with Tony Marston any more, it
    > should be obvious to any (web)developer that a URI is
    > supposed to denote a resource, and that it might have a
    > query string in it. It should also be obvious that the URL
    > is seperate from the request method.

    We are not debating what is “obvious”, we are debating what the standard says. So where does the standard say that a query string which is attached to the “action” attribute of a FORM element with “method=POST” has to be attached to the form data and not as a separate query? Unless you can quote the standard which says that you should stop telling me that I am wrong!

  • vrana

    I’ve changed the $_GET definition to “An associative array of variables passed to the current script via the URL parameters.”

  • Troels Knak-Nielsen

    Excellent, vrana.