> 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!

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

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.

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.

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.

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.