New globals for PUT and DELETE

11 years ago by Kris Craig — view source — reply

unread

Hey guys,

Does anybody know why we have $_GET and $_POST, but not $_PUT and
$_DELETE? As far as I can tell, the only way to get these out currently is
to parse their values by reading the incoming stream directly.

Is there a reason why we don't want this or is it just that nobody has
actually written it yet?

--Kris

11 years ago by Peter Lind — view source — reply

unread

Last time it stranded here:
internals@lists.php.net/msg67294.html" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/msg67294.html

And I believe it's been up a number of times before that.

Hey guys,

Does anybody know why we have $_GET and $_POST, but not $_PUT and
$_DELETE? As far as I can tell, the only way to get these out currently is
to parse their values by reading the incoming stream directly.

Is there a reason why we don't want this or is it just that nobody has
actually written it yet?

--Kris

--
<hype>
WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15
</hype

11 years ago by Andrea Faulds — view source — reply

unread

Hey guys,

Does anybody know why we have $_GET and $_POST, but not $_PUT and
$_DELETE? As far as I can tell, the only way to get these out currently is
to parse their values by reading the incoming stream directly.

Is there a reason why we don't want this or is it just that nobody has
actually written it yet?

$_GET and $_POST are really misnomers. $_GET is query string parameters, $_POST is request body data.

We should just put the request bodies for all requests, not just POST, into $_POST.

--
Andrea Faulds
http://ajf.me/

11 years ago by Kris Craig — view source — reply

unread

Hey guys,

Does anybody know why we have $_GET and $_POST, but not $_PUT and
$_DELETE? As far as I can tell, the only way to get these out currently
is
to parse their values by reading the incoming stream directly.

Is there a reason why we don't want this or is it just that nobody has
actually written it yet?

$_GET and $_POST are really misnomers. $_GET is query string parameters,
$_POST is request body data.

We should just put the request bodies for all requests, not just POST,
into $_POST.

--
Andrea Faulds
http://ajf.me/

The problem with that approach though is that it would not be RESTful. I'm
developing a REST API (with the goal of 100% REST compliance) and having
PUT/DELETE variables mixed in with $_POST would not only be
counter-intuitive, but it would just present a new roadblock.
Incorporating GET in there, as well, would make things even worse.

Basically, if we have $_GET and $_POST, then we should also have $_PUT and
$_DELETE. Either that, or they should all be tossed. There's no reason
why $_PUT and $_DELETE should not also exist.

--Kris

11 years ago by Rowan Collins — view source — reply

unread

Kris Craig wrote (on 14/10/2014):

The problem with that approach though is that it would not be RESTful. I'm
developing a REST API (with the goal of 100% REST compliance) and having
PUT/DELETE variables mixed in with $_POST would not only be
counter-intuitive, but it would just present a new roadblock.

This makes no sense; there is no such thing as "PUT/DELETE variables" in
HTTP, any more than there is such things as "POST variables".

Just imagine that the variables are called $_QUERY_STRING and
$_REQUEST_BODY. They should be completely orthogonal to the request method.

Note that this is already true to an extent - you can access the query
string through $_GET on a POST request, and $_POST will exist as an
empty array.

11 years ago by Ben Ramsey — view source — reply

unread

Hey guys,

Does anybody know why we have $_GET and $_POST, but not $_PUT and
$_DELETE? As far as I can tell, the only way to get these out currently
is
to parse their values by reading the incoming stream directly.

Is there a reason why we don't want this or is it just that nobody has
actually written it yet?

$_GET and $_POST are really misnomers. $_GET is query string parameters,
$_POST is request body data.

We should just put the request bodies for all requests, not just POST,
into $_POST.

The problem with that approach though is that it would not be RESTful. I'm
developing a REST API (with the goal of 100% REST compliance) and having
PUT/DELETE variables mixed in with $_POST would not only be
counter-intuitive, but it would just present a new roadblock.
Incorporating GET in there, as well, would make things even worse.

Basically, if we have $_GET and $_POST, then we should also have $_PUT and
$_DELETE. Either that, or they should all be tossed. There's no reason
why $_PUT and $_DELETE should not also exist.

Putting everything into $_POST isn’t a question of being RESTful or not. REST in a
Web application happens at the HTTP protocol level and not the PHP level.

That said, it would be confusing to place the request body for all requests into $_POST.
You also have to consider PATCH and the potential body for other HTTP methods. The
easiest way to get the body of any HTTP request is to use the input stream:

$requestBody = file_get_contents('php://input');

I suppose we could make a super global that returns that for us, but it’s just as easy to
use the above. Additionally, you might not want to put the full body of the request into
memory like that. You might rather read the stream only a few bytes at a time.

-Ben

11 years ago by Andrey Andreev — view source — reply

unread

Hey guys,

Does anybody know why we have $_GET and $_POST, but not $_PUT and
$_DELETE? As far as I can tell, the only way to get these out currently
is
to parse their values by reading the incoming stream directly.

Is there a reason why we don't want this or is it just that nobody has
actually written it yet?

$_GET and $_POST are really misnomers. $_GET is query string parameters,
$_POST is request body data.

We should just put the request bodies for all requests, not just POST,
into $_POST.

--
Andrea Faulds
http://ajf.me/

The problem with that approach though is that it would not be RESTful. I'm
developing a REST API (with the goal of 100% REST compliance) and having
PUT/DELETE variables mixed in with $_POST would not only be
counter-intuitive, but it would just present a new roadblock.
Incorporating GET in there, as well, would make things even worse.

Basically, if we have $_GET and $_POST, then we should also have $_PUT and
$_DELETE. Either that, or they should all be tossed. There's no reason
why $_PUT and $_DELETE should not also exist.

--Kris

This has nothing to do with REST.

$_GET doesn't even relate to GET requests, it's just query parameters.
Query parameters exist in all types of requests because they are part
of the URI.
$_POST (even if only parsed for POST requests) also represents just
the request body parsed from a very specific format.

There's no reason to have $_PUT, $_DELETE, etc. because they would
represent the same thing - php://input parsed from
application/x-www-form-urlencoded.

That being said, from a purely semantic prospective, both $_GET and
$_POST should be tossed - yes. In reality, you can't do that because
virtually all PHP applications use them. But this is no reason to add
even more global vars with such misleading ... meanings.

What would be nice is to be able to register userland parsers into a
"request body parser" of some kind, so that you can have automatic
parsing depending on the Content-Type header.

Cheers,
Andrey.

11 years ago by Andrea Faulds — view source — reply

unread

That being said, from a purely semantic prospective, both $_GET and
$_POST should be tossed - yes. In reality, you can't do that because
virtually all PHP applications use them. But this is no reason to add
even more global vars with such misleading ... meanings.

Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and $_POST then. Because they’re aliases (by-reference superglobals), there’s no additional memory consumption, but we finally have saner names.

Andrea Faulds
http://ajf.me/

11 years ago by Kristopher — view source — reply

unread

Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET
and $_POST then. Because they’re aliases (by-reference superglobals),
there’s no additional memory consumption, but we finally have saner names.

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

11 years ago by Andrea Faulds — view source — reply

unread

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long:

$_QUERY - query string parameters
$_BODY - request body parameters
$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

--
Andrea Faulds
http://ajf.me/

11 years ago by Mike Dugan — view source — reply

unread

On 14 Oct 2014, at 14:27, Kristopher kristopherwilson@gmail.com wrote:

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long:

$_QUERY - query string parameters
$_BODY - request body parameters
$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

--
Andrea Faulds
http://ajf.me/

+1 for this. This would hopefully also eliminate the confusion for new developers (or not-so-new developers) who don’t quite understand that $_GET and $_POST don’t strictly relate to their HTTP verbs of the same name.

Mike Dugan

mike@mjdugan.com

11 years ago by Kris Craig — view source — reply

unread

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY
(for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes
sense, but isn’t too long:

$_QUERY - query string parameters

$_BODY - request body parameters

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

--
Andrea Faulds
http://ajf.me/

+1 for this. This would hopefully also eliminate the confusion for new
developers (or not-so-new developers) who don’t quite understand that $_GET
and $_POST don’t strictly relate to their HTTP verbs of the same name.

--

Mike Dugan

mike@mjdugan.com

That could work, though the BC breakage will be extreme. I'm not sure if
that's worth it even in a major version increment. On the other hand,
making $_PUT and $_DELETE available wouldn't break anything and wouldn't
require re-training for devs.

--Kris

11 years ago by Chris Wright — view source — reply

unread

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY
(for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes
sense, but isn’t too long:

$_QUERY - query string parameters

$_BODY - request body parameters

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

--
Andrea Faulds
http://ajf.me/

+1 for this. This would hopefully also eliminate the confusion for new
developers (or not-so-new developers) who don’t quite understand that $_GET
and $_POST don’t strictly relate to their HTTP verbs of the same name.

--

Mike Dugan

mike@mjdugan.com

That could work, though the BC breakage will be extreme. I'm not sure if
that's worth it even in a major version increment. On the other hand,
making $_PUT and $_DELETE available wouldn't break anything and wouldn't
require re-training for devs.

...but is also the wrong solution. It's not scalable, and the only
sensible way to implement them would be as aliases of $_POST, because
they would contain the same data. How does this fundamentally differ
from $_BODY (or whatever)?

11 years ago by Kris Craig — view source — reply

unread

On 14 Oct 2014, at 14:27, Kristopher kristopherwilson@gmail.com
wrote:

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY
(for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes
sense, but isn’t too long:

$_QUERY - query string parameters

$_BODY - request body parameters

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

--
Andrea Faulds
http://ajf.me/

+1 for this. This would hopefully also eliminate the confusion for new
developers (or not-so-new developers) who don’t quite understand that
$_GET
and $_POST don’t strictly relate to their HTTP verbs of the same name.

--

Mike Dugan

mike@mjdugan.com

That could work, though the BC breakage will be extreme. I'm not sure if
that's worth it even in a major version increment. On the other hand,
making $_PUT and $_DELETE available wouldn't break anything and wouldn't
require re-training for devs.

...but is also the wrong solution. It's not scalable,

How is it not scalable, exactly? It's just a couple aliases.

and the only
sensible way to implement them would be as aliases of $_POST, because
they would contain the same data. How does this fundamentally differ
from $_BODY (or whatever)?

It's not supposed to functionally differ. It's supposed to create some
better consistency and make it easier for devs to differentiate between
different REST methods when retrieving data. If REQUEST_METHOD is PUT,
then I can set the parsed params to the value of $_PUT. The aliases match
the methods used, making the code that much more readable and scalable.

--Kris

11 years ago by Chris Wright — view source — reply

unread

On 14 Oct 2014, at 14:27, Kristopher kristopherwilson@gmail.com
wrote:

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY
(for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes
sense, but isn’t too long:

$_QUERY - query string parameters

$_BODY - request body parameters

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

--
Andrea Faulds
http://ajf.me/

+1 for this. This would hopefully also eliminate the confusion for new
developers (or not-so-new developers) who don’t quite understand that
$_GET
and $_POST don’t strictly relate to their HTTP verbs of the same name.

--

Mike Dugan

mike@mjdugan.com

That could work, though the BC breakage will be extreme. I'm not sure if
that's worth it even in a major version increment. On the other hand,
making $_PUT and $_DELETE available wouldn't break anything and wouldn't
require re-training for devs.

...but is also the wrong solution. It's not scalable,

How is it not scalable, exactly? It's just a couple aliases.

Because in a few years when the FOO request method has become
commonplace we will get requests to add support for $_FOO, and then
$_BAR, and the $_CHEESE... where does it end?

and the only
sensible way to implement them would be as aliases of $_POST, because
they would contain the same data. How does this fundamentally differ
from $_BODY (or whatever)?

It's not supposed to functionally differ. It's supposed to create some
better consistency and make it easier for devs to differentiate between
different REST methods when retrieving data. If REQUEST_METHOD is PUT,
then I can set the parsed params to the value of $_PUT. The aliases match
the methods used, making the code that much more readable and scalable.

This doesn't actually help anything, though, if anything it hinders
it. You route your request based on the method, this way you would
either have to couple the first layer after routing to the method by
using a specific named superglobal at that layer, or have a
switch/case, variable variable or some other nastiness at the top
level to pick the right superglobal to the next layer.

If the form data submitted by the request entity body - always in the
same place in every HTTP request message - is always in the same data
store at the PHP layer, there's an extra decision taken away.

--Kris

To be brutally honest I see this as a discussion of highly
questionable merit anyway, due to the fact that in the overwhelming
majority of cases where the request method is not POST the entity body
will not represent HTML form data - browsers don't make requests of
these methods with the involvement of client-side scripting at the
moment (or in the foreseeable future), the content type of the request
body is highly unlikely to be something PHP would even attempt to
decode.

Sorry.

11 years ago by Mike Dugan — view source — reply

unread

--
Mike Dugan
mike@mjdugan.com

On 14 October 2014 14:57, Kris Craig kris.craig@gmail.com wrote:

On Tue, Oct 14, 2014 at 6:50 AM, Chris Wright cw@daverandom.com wrote:

...but is also the wrong solution. It's not scalable,

How is it not scalable, exactly? It's just a couple aliases.

Because in a few years when the FOO request method has become
commonplace we will get requests to add support for $_FOO, and then
$_BAR, and the $_CHEESE... where does it end?

and the only
sensible way to implement them would be as aliases of $_POST, because
they would contain the same data. How does this fundamentally differ
from $_BODY (or whatever)?

It's not supposed to functionally differ. It's supposed to create some
better consistency and make it easier for devs to differentiate between
different REST methods when retrieving data. If REQUEST_METHOD is PUT,
then I can set the parsed params to the value of $_PUT. The aliases match
the methods used, making the code that much more readable and scalable.

Sorry.
At this point I’m a bit confused about what the scope of the discussion is. Are we talking about creating more semantic aliases for $_GET and $_POST, or integrating support to retrieve data from $_POST based on the HTTP method, or a little bit of both?

—

Mike Dugan

mike@mjdugan.com

11 years ago by Rowan Collins — view source — reply

unread

It's not supposed to functionally differ. It's supposed to create some
better consistency and make it easier for devs to differentiate between
different REST methods when retrieving data. If REQUEST_METHOD is PUT,
then I can set the parsed params to the value of $_PUT. The aliases match
the methods used, making the code that much more readable and scalable.

For that to be consistent, you would need to unset $_GET on POST
requests, which would be ... unhelpful.

GET and POST are simply the wrong names. Naming more things based on
them is just engraining a mistake.

--
Rowan Collins
[IMSoP]

11 years ago by Lester Caine — view source — reply

unread

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Am I missing something. I've used $_REQUEST since day one since the form
returns are always a combination of the Post and url data ...

All right if state variables are passed with the URL, I may just use
$_GET but only because I know I'm GETting back the previous state. I
just don't see the need for this debate.

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

11 years ago by Mike Dugan — view source — reply

unread

On 14/10/14 14:41, Mike Dugan wrote:

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.
That was actually Andrea’s reply. I don’t the intent was the $_REQUEST is new, just clarifying that it would still contain the same data.

Am I missing something. I've used $_REQUEST since day one since the form
returns are always a combination of the Post and url data ...

All right if state variables are passed with the URL, I may just use
$_GET but only because I know I'm GETting back the previous state. I
just don't see the need for this debate.
The entire point of this debate is that $_GET are passed through the URL and not necessarily indicative of a GET (HTTP) action. You could just as easily POST data to a URL with parameters, so although you would access those URL params via $_GET, the HTTP request itself isn’t a GET request. If you pass state data through the URL, there’s no mandate that you're GETting anything, rather you’re accessing the query string that’s appended to the URL regardless of the HTTP action.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

--
Mike Dugan
mike@mjdugan.com

11 years ago by Park Framework — view source — reply

unread

2014-10-14 18:31 GMT+03:00 Mike Dugan mike@mjdugan.com:

The entire point of this debate is that $_GET are passed through the URL and not necessarily indicative of a GET (HTTP) action. You could just as easily POST data to a URL with parameters, so although you would access those URL params via $_GET, the HTTP request itself isn’t a GET request. If you pass state data through the URL, there’s no mandate that you're GETting anything, rather you’re accessing the query string that’s appended to the URL regardless of the HTTP action.

The main problem that we must solve - getting data as ассоц array,
from body request when request method PUT, DELETE,...

Now
file_get_contents(‘php://input') but
php://input is not available with enctype="multipart/form-data"

Need to make access to these data, in global variables for all HTTP
request methods.

11 years ago by Park Framework — view source — reply

unread

2014-10-14 16:29 GMT+03:00 Andrea Faulds ajf@ajf.me:

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long:

$_QUERY - query string parameters

$_BODY - request body parameters

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

+1
I RESTful a developer, agree this proposal!
I hope someone will write the RFC and vote for it, it is necessary to
move from words to deeds.

11 years ago by Mike Dugan — view source — reply

unread

2014-10-14 16:29 GMT+03:00 Andrea Faulds ajf@ajf.me:

On 14 Oct 2014, at 14:27, Kristopher kristopherwilson@gmail.com wrote:

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long:

$_QUERY - query string parameters

$_BODY - request body parameters

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

+1
I RESTful a developer, agree this proposal!
I hope someone will write the RFC and vote for it, it is necessary to
move from words to deeds.

--

If no one else is already working on it, I can write one up this morning/early this afternoon and submit it.

—

Mike Dugan

mike@mjdugan.com

11 years ago by Park Framework — view source — reply

unread

2014-10-14 17:09 GMT+03:00 Mike Dugan mike@mjdugan.com:

If no one else is already working on it, I can write one up this
morning/early this afternoon and submit it.

Ok
The RFC In this topic will be included support Rquest - Content-Type:
application/json?
It is mandatory for RESTFull.

11 years ago by Ben Ramsey — view source — reply

unread

2014-10-14 17:09 GMT+03:00 Mike Dugan mike@mjdugan.com:

If no one else is already working on it, I can write one up this
morning/early this afternoon and submit it.

Ok
The RFC In this topic will be included support Rquest - Content-Type:
application/json?
It is mandatory for RESTFull.

In this case, I completely disagree. There are a variety of new JSON types floating around (i.e. application/hal+json, etc.). Should we try to support them all? I don’t think so. IMO, it is the role of a framework/library to provide support for building RESTful web applications.

-Ben

11 years ago by Andrea Faulds — view source — reply

unread

2014-10-14 17:09 GMT+03:00 Mike Dugan mike@mjdugan.com:

If no one else is already working on it, I can write one up this
morning/early this afternoon and submit it.

Ok
The RFC In this topic will be included support Rquest - Content-Type:
application/json?
It is mandatory for RESTFull.

This has been discussed before. I’m not sure it’s a good idea. json_decode(file_get_contents(‘php://input')); isn’t that bad.

--
Andrea Faulds
http://ajf.me/

11 years ago by Chris Wright — view source — reply

unread

2014-10-14 17:09 GMT+03:00 Mike Dugan mike@mjdugan.com:

If no one else is already working on it, I can write one up this
morning/early this afternoon and submit it.

Ok
The RFC In this topic will be included support Rquest - Content-Type:
application/json?
It is mandatory for RESTFull.

This has been discussed before. I’m not sure it’s a good idea. json_decode(file_get_contents(‘php://input')); isn’t that bad.

JSON decoding also has optional behaviour. No more ini settings please.

11 years ago by johannes@schlueters.de — view source — reply

unread

$_BODY - request body parameters

I think this name is confusing and unclear. I don't have an alternative,
though. (Only suggestion: stick with the established name which can be
taught easily ("See method attribute in HTML <form> tag"), slightly
advanced users are used to it and don't really care, even more advanced
users use some framework/library providing higher level abstraction and
not having to care anymore, this leaves a few experts who know HTTP and
don't use a framework ... :-) )

And about the cost - mind that there always is an additional cost to any
change: Adoption to the environment. i.e. I assume there are multiple
people who scan for $_GET/$_POST/$_REQUEST/$_COOKIES/$_SERVER to find
input data while analyzing foreign code. Habits and tools need to
change.

Also when adding those the question is whether they should be true
aliases or not, i.e. what the result of

$_GET['foo'] = 23;
echo $_NEW_GET['foo'];

is.

For the latter I think any way is fine. And if we have good names I'm
open to add them, I don't consider $_BODY good, though. It has to be
short ($_HTTP_REQUEST_BODY certainly is too long) and precise, else
people stick with the comfortable thing taught in every book/tutorial.

johannes

11 years ago by Ben Ramsey — view source — reply

unread

Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and $_POST then. Because they’re aliases (by-reference superglobals), there’s no additional memory consumption, but we finally have saner names.

But they are neither the request body nor the query string at that point. They are arrays that represent them. I agree that $_GET and $_POST are left-overs from a bygone day. Introducing aliases adds more confusion, IMHO.

-Ben

11 years ago by Chris Wright — view source — reply

unread

That being said, from a purely semantic prospective, both $_GET and
$_POST should be tossed - yes. In reality, you can't do that because
virtually all PHP applications use them. But this is no reason to add
even more global vars with such misleading ... meanings.

Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and $_POST then. Because they’re aliases (by-reference superglobals), there’s no additional memory consumption, but we finally have saner names.

$_BODY and $_QUERY would be better, IMHO. The brevity would be
consistent both historically and with other existing superglobal
names, and at least with $_QUERY_STRING the data is not a string.

I suggested this a while ago, people didn't like the idea, and I'm not
sure I do any more, either. We'd do much better focusing on creating a
standard native request object which provides clean access to this
data, and other things that are clumsy at the moment, such as request
headers.

11 years ago by Ben Ramsey — view source — reply

unread

I suggested this a while ago, people didn't like the idea, and I'm not
sure I do any more, either. We'd do much better focusing on creating a
standard native request object which provides clean access to this
data, and other things that are clumsy at the moment, such as request
headers.

Agreed, and it seems that’s what PHP-FIG is working on for user land:
https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md

-Ben

11 years ago by Chris Wright — view source — reply

unread

I suggested this a while ago, people didn't like the idea, and I'm not
sure I do any more, either. We'd do much better focusing on creating a
standard native request object which provides clean access to this
data, and other things that are clumsy at the moment, such as request
headers.

Agreed, and it seems that’s what PHP-FIG is working on for user land:
https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md

-Ben

PECL HTTP v2 already has this, actually:
http://devel-m6w6.rhcloud.com/mdref/http/Env/Request#

Also, I think Mike got the naming right there as well, $form is the
accurate description of what it is.

11 years ago by Andrea Faulds — view source — reply

unread

Also, I think Mike got the naming right there as well, $form is the
accurate description of what it is.

You’re right, actually. multipart and url-encoded are usually produced by forms, and other types of request bodies (JSON, plaintext) don’t end up in $_POST.

So $_QUERY and $_FORM, then. That sounds about right.

I suppose $_QUERY is technically incorrect for similar reasons, in that if you have a plain parameter-less query string (e.g. http://example.com/foobar.php?query%20string) it won’t end up in $_GET… but I don’t think that’s widely used, and there are only two formats that come after the question mark. If you really need the raw string, it’s in $_SERVER anyway. So that’s not really a problem.

Andrea Faulds
http://ajf.me/

11 years ago by Mike Dugan — view source — reply

unread

On 14 Oct 2014, at 14:53, Chris Wright cw@daverandom.com wrote:

Also, I think Mike got the naming right there as well, $form is the
accurate description of what it is.

You’re right, actually. multipart and url-encoded are usually produced by forms, and other types of request bodies (JSON, plaintext) don’t end up in $_POST.

So $_QUERY and $_FORM, then. That sounds about right.

I suppose $_QUERY is technically incorrect for similar reasons, in that if you have a plain parameter-less query string (e.g. http://example.com/foobar.php?query%20string) it won’t end up in $_GET… but I don’t think that’s widely used, and there are only two formats that come after the question mark. If you really need the raw string, it’s in $_SERVER anyway. So that’s not really a problem.

Andrea Faulds
http://ajf.me/

Did I just name a global variable? W00t!

Anyhow, yeah neither one is technically 100% correct, but like Andrea said, the majority of usage will be from forms and query strings with parameters. At any rate, it’s makes more sense semantically in the context of what the var actually contains than $_GET and $_POST ever will.

—
Mike Dugan
mike@mjdugan.com

11 years ago by Ben Ramsey — view source — reply

unread

So $_QUERY and $_FORM, then. That sounds about right.

Did I just name a global variable? W00t!

Anyhow, yeah neither one is technically 100% correct, but like Andrea said, the majority of usage will be from forms and query strings with parameters. At any rate, it’s makes more sense semantically in the context of what the var actually contains than $_GET and $_POST ever will.

I’m cool with $_QUERY and $_FORM. They make much more sense and don’t try to use HTTP verbs, which can confuse the content and semantics of the data they contain. Plus, they would just alias $_GET and $_POST, respectively, right?

-Ben

11 years ago by Andrea Faulds — view source — reply

unread

+1

I’m cool with $_QUERY and $_FORM. They make much more sense and don’t try to use HTTP verbs, which can confuse the content and semantics of the data they contain. Plus, they would just alias $_GET and $_POST, respectively, right?

That’s my idea, yes. They’d be implemented essentially as by-ref assignments internally.

Andrea Faulds
http://ajf.me/

11 years ago by Mike Dugan — view source — reply

unread

On Oct 14, 2014, at 9:08 AM, Mike Dugan mike@mjdugan.com wrote:

On October 14, 2014 at 10:04:00 AM, Andrea Faulds (ajf@ajf.me) wrote:

So $_QUERY and $_FORM, then. That sounds about right.

Did I just name a global variable? W00t!

Anyhow, yeah neither one is technically 100% correct, but like Andrea said, the majority of usage will be from forms and query strings with parameters. At any rate, it’s makes more sense semantically in the context of what the var actually contains than $_GET and $_POST ever will.

-Ben

That’s my understanding. There’s also some discussion about deriving data from $_POST/$_FORM that is intended for use with other HTTP verbs, I’m still trying to ascertain exactly what was in mind there (Andrea I think you suggested that?)
--
Mike Dugan
mike@mjdugan.com

11 years ago by Andrea Faulds — view source — reply

unread

That’s my understanding. There’s also some discussion about deriving data from $_POST/$_FORM that is intended for use with other HTTP verbs, I’m still trying to ascertain exactly what was in mind there (Andrea I think you suggested that?)

So, we currently parse multipart and url-encoded request bodies for POST and put them in $_POST. I'm just thinking there's no good reason not to do so for any other request method. However, to avoid confusion, we alias it to $_FORM so it's clear it's not only for POST.

Andrea Faulds
http://ajf.me/

11 years ago by Chris Wright — view source — reply

unread

So $_QUERY and $_FORM, then. That sounds about right.

Did I just name a global variable? W00t!

Anyhow, yeah neither one is technically 100% correct, but like Andrea
said, the majority of usage will be from forms and query strings with
parameters. At any rate, it’s makes more sense semantically in the context
of what the var actually contains than $_GET and $_POST ever will.

+1

I’m cool with $_QUERY and $_FORM. They make much more sense and don’t try to
use HTTP verbs, which can confuse the content and semantics of the data they
contain. Plus, they would just alias $_GET and $_POST, respectively, right?

-Ben

That’s my understanding. There’s also some discussion about deriving data
from $_POST/$_FORM that is intended for use with other HTTP verbs, I’m still
trying to ascertain exactly what was in mind there (Andrea I think you
suggested that?)

Well the top of the discussion was suggesting $_PUT and $_DELETE,
which would imply that entity bodies are processed for all HTTP verbs,
the more semantic names for the existing variables came out of this
suggestion (as putting data from other request methods into $_POST
isn't very intuitive).

I'm about +0.5 on both. The name aliases are more semantically
correct, and that's a good thing, but also not entirely necessary.
Processing entity bodies regardless of request method (baring in mind
that this is still content type dependent) is certainly harmless and
may be useful to someone somewhere.

I still think this deflects focus from what would be more useful here:
a native request abstraction object, which provides access to all
elements of the request without a) splitting them up into distinct
global data stores as the current $_GET, $_POST, $_COOKIE does and b)
mixing request data in with server environment data, as $_SERVER
currently does.

11 years ago by Michael Wallner — view source — reply

unread

Did I just name a global variable? W00t!

I guess Chris meant pecl_http's http\Env\Request::$form property.

--
Regards,
Mike

11 years ago by johannes@schlueters.de — view source — reply

unread

Agreed, and it seems that’s what PHP-FIG is working on for user land:
https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md

It is great that such things are standardized in userland form - I'm
strongly in favor of having the core language only the foundation.
Userland code can be managed way simpler than anything in the core
runtime.

PECL HTTP v2 already has this, actually:
http://devel-m6w6.rhcloud.com/mdref/http/Env/Request#

Also, I think Mike got the naming right there as well, $form is the
accurate description of what it is.

For me <form method="get"> is a form, too. "get" even is default for
HTML <form>s. This wouldn't show up in $_FORM, though.

johannes

11 years ago by Michael Wallner — view source — reply

unread

PECL HTTP v2 already has this, actually:
http://devel-m6w6.rhcloud.com/mdref/http/Env/Request#

Also, I think Mike got the naming right there as well, $form is the
accurate description of what it is.

For me <form method="get"> is a form, too. "get" even is default for
HTML <form>s. This wouldn't show up in $_FORM, though.

As much as I'd like to have as many synapses to always grok those edge
cases, I think this is nitpicking :)

For me the "form" term in case if HTTP request relates to the content
type; GET forms obviously have no content type.

Anyway, IIRC I started a similar discussion after a few glass of Scotch,
and I'm in the "leave it alone" department now, too.

--
Regards,
Mike

11 years ago by Kris Craig — view source — reply

unread

That being said, from a purely semantic prospective, both $_GET and
$_POST should be tossed - yes. In reality, you can't do that because
virtually all PHP applications use them. But this is no reason to add
even more global vars with such misleading ... meanings.

Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET
and $_POST then. Because they’re aliases (by-reference superglobals),
there’s no additional memory consumption, but we finally have saner names.

Andrea Faulds
http://ajf.me/

I don't think that would be a good idea, either. They require more typing
and it'd probably be a lot easier for devs to remember which one means GET
and which one means POST.

The fact that $_PUT and $_DELETE aren't necessary because we can use other
approaches to get that data is irrelevant. Having globals for two REST
methods but not the other two is very counter-intuitive from a dev
standpoint. We just recently discussed how PHP tends to have duplicate
ways of doing something in order to make it as easy as possible. I believe
this is one of those times. It would make it a lot easier for devs,
particularly the ones less experienced with REST, to create APIs that
actually use the correct methods without running into the confusion over
why there's a $_GET and a $_POST but not a $_PUT or a $_DELETE.

PHP is supposed to be KISS, right? Well, the current reliance on
php://input for two methods but not the other two invites confusion. That
makes it less-than simple, I believe.

Removing or renaming $_GET and $_POST would also create confusion and
almost certainly cause widespread BC breakage on a pretty massive scale.
And there's really no gain to offset that. So that just leaves us with
either continuing to have two REST methods but not the others or add a
$_PUT and a $_DELETE, even if they just alias to php://input again.

--Kris

11 years ago by Mike Dugan — view source — reply

unread

--
Mike Dugan
mike@mjdugan.com

On Tue, Oct 14, 2014 at 6:25 AM, Andrea Faulds ajf@ajf.me wrote:

On 14 Oct 2014, at 14:23, Andrey Andreev narf@devilix.net wrote:

That being said, from a purely semantic prospective, both $_GET and
$_POST should be tossed - yes. In reality, you can't do that because
virtually all PHP applications use them. But this is no reason to add
even more global vars with such misleading ... meanings.

Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET
and $_POST then. Because they’re aliases (by-reference superglobals),
there’s no additional memory consumption, but we finally have saner names.
--
Andrea Faulds
http://ajf.me/

--Kris
How are these RESTful methods? $_GET accepts query strings, that’s not part of the spec for RESTful GET requests unless I missed something. I also don’t see the worldwide breakage and confusion that would be caused - no one is proposing to drop $_GET and $_POST but rather to create more semantic aliases for them.

—

Mike Dugan

mike@mjdugan.com

11 years ago by Andrea Faulds — view source — reply

unread

I don't think that would be a good idea, either. They require more typing
and it'd probably be a lot easier for devs to remember which one means GET
and which one means POST.

I’ve already proposed the shorter $_QUERY and $_BODY.

PHP is supposed to be KISS, right? Well, the current reliance on
php://input for two methods but not the other two invites confusion. That
makes it less-than simple, I believe.

Removing or renaming $_GET and $_POST would also create confusion and
almost certainly cause widespread BC breakage on a pretty massive scale.

I never said anything about removing $_GET or $_POST. I suggested adding saner aliases.

And there's really no gain to offset that. So that just leaves us with
either continuing to have two REST methods but not the others or add a
$_PUT and a $_DELETE, even if they just alias to php://input again.

Adding $_PUT and $_DELETE is silly. We already have a nonsensical system where $_GET isn’t about GET, but about query string parameters, and $_POST isn’t about POST, but the request body. We should create sane aliases ($_QUERY and $_BODY) and extend $_POST/$_BODY to support request bodies from any method.

This would make things actually simpler, and less confusing, as we stop pretending $_GET is about GET and $_POST is about POST. By using $_QUERY, it’s clear it’s about query string parameters, which any method can have. Similarly, by using $_BODY, it’s clear it’s about request body parameters, which any method can also have.

Sure, all existing code uses $_GET and $_POST and they won’t go away any time soon. But we would have saner names that people writing new code can use.

--
Andrea Faulds
http://ajf.me/

11 years ago by Kris Craig — view source — reply

unread

I don't think that would be a good idea, either. They require more
typing
and it'd probably be a lot easier for devs to remember which one means
GET
and which one means POST.

I’ve already proposed the shorter $_QUERY and $_BODY.

PHP is supposed to be KISS, right? Well, the current reliance on
php://input for two methods but not the other two invites confusion.
That
makes it less-than simple, I believe.

Removing or renaming $_GET and $_POST would also create confusion and
almost certainly cause widespread BC breakage on a pretty massive scale.

I never said anything about removing $_GET or $_POST. I suggested adding
saner aliases.

Ok, that was my bad. I misinterpreted.

And there's really no gain to offset that. So that just leaves us with
either continuing to have two REST methods but not the others or add a
$_PUT and a $_DELETE, even if they just alias to php://input again.

Adding $_PUT and $_DELETE is silly.

No more silly than $_GET and $_POST are now. But either way, we should try
to make things consistent. This inconsistency only serves to invite
confusion.

We already have a nonsensical system where $_GET isn’t about GET, but
about query string parameters, and $_POST isn’t about POST, but the request
body. We should create sane aliases ($_QUERY and $_BODY) and extend
$_POST/$_BODY to support request bodies from any method.

This would make things actually simpler, and less confusing, as we stop
pretending $_GET is about GET and $_POST is about POST. By using $_QUERY,
it’s clear it’s about query string parameters, which any method can have.
Similarly, by using $_BODY, it’s clear it’s about request body parameters,
which any method can also have.

That's a good point. Unfortunately, $_GET and $_POST aren't going away
anytime soon. And in the meantime, we should at least have $_PUT and
$_DELETE alias to $_POST so devs have the option of using them.

Sure, all existing code uses $_GET and $_POST and they won’t go away any
time soon. But we would have saner names that people writing new code can
use.

--
Andrea Faulds
http://ajf.me/

11 years ago by Ben Ramsey — view source — reply

unread

Removing or renaming $_GET and $_POST would also create confusion and
almost certainly cause widespread BC breakage on a pretty massive scale.
And there's really no gain to offset that. So that just leaves us with
either continuing to have two REST methods but not the others or add a
$_PUT and a $_DELETE, even if they just alias to php://input again.

There is no standard way to deal with the data in $_PUT and $_DELETE. In fact,
DELETE rarely, if ever, contains a request body. RFC 7231 (section 4.3.5) says
this about payloads within DELETE requests:

A payload within a DELETE request message has no defined semantics;
sending a payload body on a DELETE request might cause some existing
implementations to reject the request.

There’s no standard way to deal with the data in $_POST, either, except that HTML
forms send POST data by default as application/x-www-form-urlencoded, making it
easy for PHP to parse. When building RESTful APIs, that content type is rarely
used in favor of using JSON or XML content types, so even there the $_POST
super global in PHP is useless. You must still use php://input to get the request
body for those POST requests.

While it might make sense to also include $_PUT, $_DELETE, $_PATCH, etc.,
we would also need to build in parsers for a variety of content types, and I don’t
think this is the job of the PHP engine to look at the content type on every request
and attempt to parse it in the way the developer expects it to be parsed. That’s
much better left up to the developer, extensions, and libraries.

Ben

11 years ago by Alain Williams — view source — reply

unread

Hey guys,

Does anybody know why we have $_GET and $_POST, but not $_PUT and
$_DELETE? As far as I can tell, the only way to get these out currently is
to parse their values by reading the incoming stream directly.

Is there a reason why we don't want this or is it just that nobody has
actually written it yet?

$_GET and $_POST are really misnomers. $_GET is query string parameters, $_POST is request body data.

We should just put the request bodies for all requests, not just POST, into $_POST.

Unless I have misunderstood what you are saying ...

as a developer I do want to know the difference between fields in a POST form
and query items on the URL. I will sometimes use them together, eg:

<form action="?context=something" method="post" >
...

and specifically check $_GET['context'] - there might be a $_POST['context'] but
that is treated completely differently.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h

11 years ago by Rowan Collins — view source — reply

unread

Alain Williams wrote (on 14/10/2014):

Hey guys,

Does anybody know why we have $_GET and $_POST, but not $_PUT and
$_DELETE? As far as I can tell, the only way to get these out currently is
to parse their values by reading the incoming stream directly.

Is there a reason why we don't want this or is it just that nobody has
actually written it yet?
$_GET and $_POST are really misnomers. $_GET is query string parameters, $_POST is request body data.

We should just put the request bodies for all requests, not just POST, into $_POST.
Unless I have misunderstood what you are saying ...

as a developer I do want to know the difference between fields in a POST form
and query items on the URL. I will sometimes use them together, eg:
 <form action="?context=something" method="post" >
 ...
and specifically check $_GET['context'] - there might be a $_POST['context'] but
that is treated completely differently.

You have misunderstood: the request body is the data sent with the HTTP
request, separate from the URL.

11 years ago by Leigh — view source — reply

unread

I'm sure the previous 50+ messages are bikeshedding on names for new
superglobals, so going to skip them (sorry for anyone who had a valid
point).

So, my 2p, the entity bodies of PUT and DELETE should go in $_POST
(yes, keeping that name) - I see no reason to cater for other methods
outside of the HTTP 1.1 spec. (Yes, looking at you WebDAV, I don't
care about you)

I am happy to do RFC + patch as required for this change.

11 years ago by Ben Ramsey — view source — reply

unread

Hey guys,

Does anybody know why we have $_GET and $_POST, but not $_PUT and
$_DELETE? As far as I can tell, the only way to get these out currently is
to parse their values by reading the incoming stream directly.

Is there a reason why we don't want this or is it just that nobody has
actually written it yet?

—Kris

This is due to the history of HTML forms sending POST requests with the Content-Type application/x-www-form-urlencoded. That is, all the fields are key/value pairs and may be easily converted into a PHP array. If you use POST with application/json, nothing appears in $_POST, for example.

In practice, we could support $_PUT and $_DELETE for requests that use application/x-www-form-urlencoded, but most folks implementing PUT and DELETE do not use application/x-www-form-urlencoded for these requests.

I would venture to say that most people implementing PUT requests accept application/json and most DELETE requests have no body at all. So, $_PUT and $_DELETE superglobals wouldn’t make sense.

-Ben

11 years ago by Kris Craig — view source — reply

unread

Hey guys,

Does anybody know why we have $_GET and $_POST, but not $_PUT and
$_DELETE? As far as I can tell, the only way to get these out currently
is
to parse their values by reading the incoming stream directly.

Is there a reason why we don't want this or is it just that nobody has
actually written it yet?

—Kris

This is due to the history of HTML forms sending POST requests with the
Content-Type application/x-www-form-urlencoded. That is, all the fields are
key/value pairs and may be easily converted into a PHP array. If you use
POST with application/json, nothing appears in $_POST, for example.

In practice, we could support $_PUT and $_DELETE for requests that use
application/x-www-form-urlencoded, but most folks implementing PUT and
DELETE do not use application/x-www-form-urlencoded for these requests.

I would venture to say that most people implementing PUT requests accept
application/json and most DELETE requests have no body at all. So, $_PUT
and $_DELETE superglobals wouldn’t make sense.

-Ben

I'm not following your logic, Ben. Just because there are a lot of people
out there who don't understand REST, doesn't mean we shouldn't add support
for the other methods. Besides, if anyone wants to develop a truly RESTful
API in PHP-- which a lot of devs are doing every day-- not giving them
$_PUT and $_DELETE is what wouldn't make any sense. I'm writing an API now
and the lack of those two globals has proven to be a real pain in the ass.
The Content-Type argument really isn't an issue since the API developer
should be setting the right headers for the request method, anyway.

I don't see any gain in not making those globals available. All it does is
present both inconvenience and inconsistency for any REST-based project.

--Kris

11 years ago by Rowan Collins — view source — reply

unread

Kris Craig wrote (on 14/10/2014):

The Content-Type argument really isn't an issue since the API developer
should be setting the right headers for the request method, anyway.

I think the point is that there's currently no mechanism for data from
anything other than application/x-www-form-urlencoded and
multipart/form-data to end up in $_POST anyway.

There was a discussion of that a while back, and I think there's talk on
PHP-FIG about how standardising HTTP interfaces. It comes down to
needing some flexibility over /how/ different content types are parsed,
which makes a function-call based API make more sense than one that
silently slurps the data on every page load.

11 years ago by Mike Dugan — view source — reply

unread

On 10/14/2014 06:29 AM, Andrea Faulds wrote:

On 14 Oct 2014, at 14:27, Kristopher kristopherwilson@gmail.com wrote:

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long:

$_QUERY - query string parameters

$_BODY - request body parameters

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

It makes no sense to me to make $_BODY an alias for $_POST. $_POST
implies the default body encoding that a broswer performs on a POST
request. Making an alias called $_BODY that doesn't contain the body of
a request unless it is "POST"-encoded would be super confusing.

I think the pedantry level around this is rather high. Nobody is
actually confused about $_GET and $_POST and how and when to use them.
Adding vague aliases adds confusion to something that had no confusion
before.

-Rasmus

For clarity, $_BODY was revised to $_FORM.

I think there was some misunderstanding of the usage of $_GET earlier in this thread, although I may have misunderstood someone’s wording. Regardless, if I go out and sample 100 PHP folks, I’m fairly confident someone would make the association that either $_GET or $_POST is bound strictly to the HTTP verb of the same name. Adding aliases gives these vars a more semantic name while not causing a massive BC breakage.

The documentation would be simple and not have room for misinterpretation as I see it:

$_FORM is the exact same by-reference variable as $_POST
$_QUERY is the exact same by-reference variable as $_GET

--
Mike Dugan
mike@mjdugan.com

11 years ago by Rasmus Lerdorf — view source — reply

unread

On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (rasmus@lerdorf.com
mailto:rasmus@lerdorf.com) wrote:

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long:

$_QUERY - query string parameters

$_BODY - request body parameters

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

It makes no sense to me to make $_BODY an alias for $_POST. $_POST
implies the default body encoding that a broswer performs on a POST
request. Making an alias called $_BODY that doesn't contain the body of
a request unless it is "POST"-encoded would be super confusing.

I think the pedantry level around this is rather high. Nobody is
actually confused about $_GET and $_POST and how and when to use them.
Adding vague aliases adds confusion to something that had no confusion
before.

-Rasmus

For clarity, $_BODY was revised to $_FORM.

I think there was some misunderstanding of the usage of $_GET earlier in
this thread, although I may have misunderstood someone’s wording.
Regardless, if I go out and sample 100 PHP folks, I’m fairly confident
someone would make the association that either $_GET or $_POST is bound
strictly to the HTTP verb of the same name. Adding aliases gives these
vars a more semantic name while not causing a massive BC breakage.

I think 20+ years of history has proven this to be a non-issue. Of all
the things that people get confused by in PHP, $_GET/$_POST are right
near the bottom of the list.

-Rasmus

11 years ago by Florian Margaine — view source — reply

unread

Hi,

If it were me, I'd rather delete all the superglobals. It's a horrible API,
I don't think anyone can deny that. Now of course, it'd break a tons of
code, so I don't suggest to actually delete it.

However, instead of trying to work around current superglobals and trying
to provide meaningful names, how about actually trying to provide a correct
API?

I won't suggest a Request class, because such an interface is best left to
userland imho. However, I'd like to propose such an API:

request_get(): gets a request array/object. It only has the unparsed
request headers.
request_cookie_parse(): parses the requests cookie header in an array
similar to $_COOKIE. $_COOKIE could use this new function to build its
array.
request_cookie_get($name): gets the value of $name in the cookie. Calls
request_cookie_parse() if it hasn't been called before.
request_urlencoded_body_parse(): parses an urlencoded body. It'd give an
array similar to $_POST.
request_urlencoded_body_get($name): gets the value of $name in the parsed
urlencoded body. Calls request_urlencoded_body_parse() if it hasn't been
done before.
request_query_string_parse(): parses the query strings of a request. It'd
give an array similar to $_GET.
request_query_string_get($name): gets the value of $name in the parsed
query string. Calls request_query_string_parse() if it hasn't been called
before.

Basically, stop using the mess that superglobals currently are ($_REQUEST
or $_SERVER), and start providing a sane, very basic API. The
functionality remain the same, yet the API is actually sane.

It allows userland to use this basic API and can easily build up on it.

Maybe this is actually a non-issue and I'm thinking too much... just my
$0.02.

Regards,

On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (rasmus@lerdorf.com
mailto:rasmus@lerdorf.com) wrote:

On 14 Oct 2014, at 14:27, Kristopher kristopherwilson@gmail.com
wrote:

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps
$_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally
makes sense, but isn’t too long:

$_QUERY - query string parameters

$_BODY - request body parameters

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

It makes no sense to me to make $_BODY an alias for $_POST. $_POST
implies the default body encoding that a broswer performs on a POST
request. Making an alias called $_BODY that doesn't contain the body of
a request unless it is "POST"-encoded would be super confusing.

I think the pedantry level around this is rather high. Nobody is
actually confused about $_GET and $_POST and how and when to use them.
Adding vague aliases adds confusion to something that had no confusion
before.

-Rasmus

For clarity, $_BODY was revised to $_FORM.

I think there was some misunderstanding of the usage of $_GET earlier in
this thread, although I may have misunderstood someone’s wording.
Regardless, if I go out and sample 100 PHP folks, I’m fairly confident
someone would make the association that either $_GET or $_POST is bound
strictly to the HTTP verb of the same name. Adding aliases gives these
vars a more semantic name while not causing a massive BC breakage.

I think 20+ years of history has proven this to be a non-issue. Of all
the things that people get confused by in PHP, $_GET/$_POST are right
near the bottom of the list.

-Rasmus

--

--
Florian Margaine

11 years ago by Florian Margaine — view source — reply

unread

Erratum: all the request_* functions except request_get() take the request
object/array as 1st argument.

Le 14 oct. 2014 18:21, "Florian Margaine" florian@margaine.com a écrit :

Hi,

If it were me, I'd rather delete all the superglobals. It's a horrible
API, I don't think anyone can deny that. Now of course, it'd break a tons
of code, so I don't suggest to actually delete it.

However, instead of trying to work around current superglobals and trying
to provide meaningful names, how about actually trying to provide a correct
API?

I won't suggest a Request class, because such an interface is best left
to userland imho. However, I'd like to propose such an API:

request_get(): gets a request array/object. It only has the unparsed
request headers.
request_cookie_parse(): parses the requests cookie header in an array
similar to $_COOKIE. $_COOKIE could use this new function to build its
array.
request_cookie_get($name): gets the value of $name in the cookie. Calls
request_cookie_parse() if it hasn't been called before.
request_urlencoded_body_parse(): parses an urlencoded body. It'd give an
array similar to $_POST.
request_urlencoded_body_get($name): gets the value of $name in the parsed
urlencoded body. Calls request_urlencoded_body_parse() if it hasn't been
done before.
request_query_string_parse(): parses the query strings of a request. It'd
give an array similar to $_GET.
request_query_string_get($name): gets the value of $name in the parsed
query string. Calls request_query_string_parse() if it hasn't been called
before.

Basically, stop using the mess that superglobals currently are ($_REQUEST
or $_SERVER), and start providing a sane, very basic API. The
functionality remain the same, yet the API is actually sane.

It allows userland to use this basic API and can easily build up on it.

Maybe this is actually a non-issue and I'm thinking too much... just my
$0.02.

Regards,

On Tue, Oct 14, 2014 at 6:18 PM, Rasmus Lerdorf rasmus@lerdorf.com
wrote:

On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (rasmus@lerdorf.com
mailto:rasmus@lerdorf.com) wrote:

On 14 Oct 2014, at 14:27, Kristopher kristopherwilson@gmail.com
wrote:

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps
$_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally
makes sense, but isn’t too long:

$_QUERY - query string parameters

$_BODY - request body parameters

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

It makes no sense to me to make $_BODY an alias for $_POST. $_POST
implies the default body encoding that a broswer performs on a POST
request. Making an alias called $_BODY that doesn't contain the body
of
a request unless it is "POST"-encoded would be super confusing.

I think the pedantry level around this is rather high. Nobody is
actually confused about $_GET and $_POST and how and when to use them.
Adding vague aliases adds confusion to something that had no confusion
before.

-Rasmus

For clarity, $_BODY was revised to $_FORM.

I think there was some misunderstanding of the usage of $_GET earlier
in
this thread, although I may have misunderstood someone’s wording.
Regardless, if I go out and sample 100 PHP folks, I’m fairly confident
someone would make the association that either $_GET or $_POST is bound
strictly to the HTTP verb of the same name. Adding aliases gives these
vars a more semantic name while not causing a massive BC breakage.

I think 20+ years of history has proven this to be a non-issue. Of all
the things that people get confused by in PHP, $_GET/$_POST are right
near the bottom of the list.

-Rasmus

--

--
Florian Margaine

11 years ago by Rowan Collins — view source — reply

unread

I think 20+ years of history has proven this to be a non-issue. Of all
the things that people get confused by in PHP, $_GET/$_POST are right
near the bottom of the list.

The popularity of REST is what has changed this. Until people started
writing RESTful APIs, only two HTTP request types were in common use.
Nobody was confused about where PUT method data would end up, because
nobody processed any PUT methods.

It makes no sense to me to make $_BODY an alias for $_POST. $_POST
implies the default body encoding that a broswer performs on a POST
request. Making an alias called $_BODY that doesn't contain the body of
a request unless it is "POST"-encoded would be super confusing.

The encoding has no relationship with the request type, even in browsers

the default encoding of a POST form is actually the same encoding used
to produce a URL form a GET form.

And in case it's not clear, the suggestion is that $_POST should be
populated on PUT and DELETE methods as well.

--
Rowan Collins
[IMSoP]

11 years ago by Rasmus Lerdorf — view source — reply

unread

I think 20+ years of history has proven this to be a non-issue. Of all
the things that people get confused by in PHP, $_GET/$_POST are right
near the bottom of the list.

The popularity of REST is what has changed this. Until people started
writing RESTful APIs, only two HTTP request types were in common use.
Nobody was confused about where PUT method data would end up, because
nobody processed any PUT methods.

It makes no sense to me to make $_BODY an alias for $_POST. $_POST
implies the default body encoding that a broswer performs on a POST
request. Making an alias called $_BODY that doesn't contain the body of
a request unless it is "POST"-encoded would be super confusing.

The encoding has no relationship with the request type, even in browsers

the default encoding of a POST form is actually the same encoding used
to produce a URL form a GET form.

Sure, but $_GET/$_POST do. They were not named to match HTTP primitives.
They were named to match form methods. As in form method="get" and
method="post". And here the default encoding the browsers use for these
two methods definitely matter.

-Rasmus

11 years ago by Kris Craig — view source — reply

unread

I think 20+ years of history has proven this to be a non-issue. Of all
the things that people get confused by in PHP, $_GET/$_POST are right
near the bottom of the list.

The popularity of REST is what has changed this. Until people started
writing RESTful APIs, only two HTTP request types were in common use.
Nobody was confused about where PUT method data would end up, because
nobody processed any PUT methods.

It makes no sense to me to make $_BODY an alias for $_POST. $_POST
implies the default body encoding that a broswer performs on a POST
request. Making an alias called $_BODY that doesn't contain the body of
a request unless it is "POST"-encoded would be super confusing.

The encoding has no relationship with the request type, even in browsers

the default encoding of a POST form is actually the same encoding used
to produce a URL form a GET form.

Sure, but $_GET/$_POST do. They were not named to match HTTP primitives.
They were named to match form methods. As in form method="get" and
method="post". And here the default encoding the browsers use for these
two methods definitely matter.

-Rasmus

--

I understand that that was the original intent. However, the use cases have
expanded beyond simply handling HTML form submissions. People are writing
REST APIs using PHP now, and having GET/POST but not PUT/DELETE has indeed
led to confusion. I only posted this after doing a Google search and
finding tons of results from people mistakenly asking why PHP doesn't
handle PUT/DELETE requests or complaining how the lack of aliases for
PUT/DELETE leads to inconsistency in the code.

Personally, I like the idea of using more appropriately named aliases,
particularly if they're roughly the same number of characters. However, we
would need to allow at least several years for people to adopt the new
globals before deprecating $_GET and $_POST. Ultimately, they will either
need to be deprecated or the $_PUT and $_DELETE aliases will need to be
added, otherwise the issue I raised would remain unresolved.

--Kris

11 years ago by Zeev Suraski — view source — reply

unread

Personally, I like the idea of using more appropriately named aliases,
particularly if they're roughly the same number of characters. However,
we
would need to allow at least several years for people to adopt the new
globals before deprecating $_GET and $_POST. Ultimately, they will either
need to be deprecated or the $_PUT and $_DELETE aliases will need to be
added, otherwise the issue I raised would remain unresolved.

Kris,

Don't get this the wrong way, but $_GET and $_POST are not going to be
deprecated.

Whether or not we need $_PUT or $_DELETE is a separate, independent question
from the axiom that $_GET and $_POST are here to stay. Personally, I don't
think they make sense as Rasmus pointed out that $_GET and $_POST were never
about HTTP methods but form methods, and there's really nothing missing from
PHP today to enable successful & easy implementation of RESTful interfaces.

Zeev

11 years ago by Park Framework — view source — reply

unread

2014-10-15 0:56 GMT+03:00 Zeev Suraski zeev@zend.com:

PHP today to enable successful & easy implementation of RESTful interfaces.

No, now PHP not successful & not easy implementation of RESTful interfaces.

Try to send a parameter in the body, by PUT method, for reading
parameters have to use an ugly way file_get_contents(‘php://input')

But yet worst, you can not do upload files and send parameters because

php://input is not available with enctype="multipart/form-data"

Main objective is to get the parameters of the request body in Global
change, as name this variable, is not so important.

11 years ago by Zeev Suraski — view source — reply

unread

-----Original Message-----
From: Park Framework [mailto:park.framework@gmail.com]
Sent: Wednesday, October 15, 2014 1:16 AM
To: Zeev Suraski
Cc: Kris Craig; Rasmus Lerdorf; Rowan Collins; PHP internals list
Subject: Re: [PHP-DEV] New globals for PUT and DELETE

2014-10-15 0:56 GMT+03:00 Zeev Suraski zeev@zend.com:

PHP today to enable successful & easy implementation of RESTful
interfaces.

No, now PHP not successful & not easy implementation of RESTful
interfaces.

Projects like Apigility beg to differ.

Zeev

11 years ago by Park Framework — view source — reply

unread

I also implement RESTFul projects, argue need to modify PHP to make it
convenient for RESTFul :)

The problem is not in the names of global variables, the problem is a
lack of data they, if method request PUT, DELETE.

But there is nothing wrong with the renaming and adding aliases,
rename $HTTP_GET_VARS, over time, are used to and have begun to use

2014-10-15 1:21 GMT+03:00 Zeev Suraski zeev@zend.com:

-----Original Message-----
From: Park Framework [mailto:park.framework@gmail.com]
Sent: Wednesday, October 15, 2014 1:16 AM
To: Zeev Suraski
Cc: Kris Craig; Rasmus Lerdorf; Rowan Collins; PHP internals list
Subject: Re: [PHP-DEV] New globals for PUT and DELETE

2014-10-15 0:56 GMT+03:00 Zeev Suraski zeev@zend.com:

PHP today to enable successful & easy implementation of RESTful
interfaces.

No, now PHP not successful & not easy implementation of RESTful
interfaces.

Projects like Apigility beg to differ.

Zeev

11 years ago by Kris Craig — view source — reply

unread

I also implement RESTFul projects, argue need to modify PHP to make it
convenient for RESTFul :)

The problem is not in the names of global variables, the problem is a
lack of data they, if method request PUT, DELETE.

But there is nothing wrong with the renaming and adding aliases,
rename $HTTP_GET_VARS, over time, are used to and have begun to use

2014-10-15 1:21 GMT+03:00 Zeev Suraski zeev@zend.com:

-----Original Message-----
From: Park Framework [mailto:park.framework@gmail.com]
Sent: Wednesday, October 15, 2014 1:16 AM
To: Zeev Suraski
Cc: Kris Craig; Rasmus Lerdorf; Rowan Collins; PHP internals list
Subject: Re: [PHP-DEV] New globals for PUT and DELETE

2014-10-15 0:56 GMT+03:00 Zeev Suraski zeev@zend.com:

PHP today to enable successful & easy implementation of RESTful
interfaces.

No, now PHP not successful & not easy implementation of RESTful
interfaces.

Projects like Apigility beg to differ.

Zeev

It is worth noting that nearly all APIs that claim to be RESTful are not.

--Kris

11 years ago by Stas Malyshev — view source — reply

unread

Hi!

PHP today to enable successful & easy implementation of RESTful
interfaces.

Having done this, I beg to differ.

Try to send a parameter in the body, by PUT method, for reading
parameters have to use an ugly way file_get_contents(‘php://input')

What exactly is the problem in this one-liner?

But yet worst, you can not do upload files and send parameters because

php://input is not available with enctype="multipart/form-data"

I'm not sure I understand what you're trying to do, could you explain in
more detail with examples?

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

11 years ago by Park Framework — view source — reply

unread

2014-10-15 4:30 GMT+03:00 Stas Malyshev smalyshev@sugarcrm.com:

Hi!

PHP today to enable successful & easy implementation of RESTful
interfaces.

Having done this, I beg to differ.

Try to send a parameter in the body, by PUT method, for reading
parameters have to use an ugly way file_get_contents(‘php://input')

What exactly is the problem in this one-liner?

But yet worst, you can not do upload files and send parameters because

php://input is not available with enctype="multipart/form-data"

I'm not sure I understand what you're trying to do, could you explain in
more detail with examples?

PUT /url
Content-type: application/x-www-form-urlencoded

parse_str (file_get_contents(‘php://input'), $_POST) // Ok

PUT /url
Content-type: multipart/mixed; boundary="xxxx"

file_get_contents(‘php://input') // Empty string

11 years ago by Ralph Schindler — view source — reply

unread

I'm not sure I understand what you're trying to do, could you explain in
more detail with examples?

PUT /url
Content-type: application/x-www-form-urlencoded

parse_str (file_get_contents(‘php://input'), $_POST) // Ok

PUT /url
Content-type: multipart/mixed; boundary="xxxx"

file_get_contents(‘php://input') // Empty string

You are missing information in your example. First, PHP doesn't do
content negotiation for every Content-Type known to send serialized
data, it is extremely selective in that AFAIK, url/form encoded
Content-Types, when POSTed, will be content-negotiated, parsed, and
their resultant will populate the $_POST superglobal.

Moreover, your 2nd example does not suggest that an HTTP request was
sent with a body to demonstrate there is a bug here.

With a php script being served at index.php with the following contents:

<?php
var_dump(file_get_contents('php://input'));

Here is a demonstration of this script, and a successful read of the
request body:

$ echo 'FOOOO=BARRRRR' | http --verbose PUT localhost:8000
Content-Type:'multipart/mime; boundry=xxxxx'

PUT / HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Content-Length: 14
Content-Type: multipart/mime; boundry=xxxxx
Host: localhost:8000
User-Agent: HTTPie/0.8.0

FOOOO=BARRRRR

HTTP/1.1 200 OK
Connection: close
Content-type: text/html
Host: localhost:8000
X-Powered-By: PHP/5.5.15

string(14) "FOOOO=BARRRRR
"

-ralph

11 years ago by Rowan Collins — view source — reply

unread

I'm not sure I understand what you're trying to do, could you
explain in
more detail with examples?

PUT /url
Content-type: application/x-www-form-urlencoded

parse_str (file_get_contents(‘php://input'), $_POST) // Ok

PUT /url
Content-type: multipart/mixed; boundary="xxxx"

file_get_contents(‘php://input') // Empty string

Here is a demonstration of this script, and a successful read of the
request body:

$ echo 'FOOOO=BARRRRR' | http --verbose PUT localhost:8000
Content-Type:'multipart/mime; boundry=xxxxx'

PUT / HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Content-Length: 14
Content-Type: multipart/mime; boundry=xxxxx
Host: localhost:8000
User-Agent: HTTPie/0.8.0

I'm not sure if itmakes a difference, but you mistyped the content type there: it should be multipart/mixed, not multipart/mime.

There may also be version differences at play here, because I think the behaviour of php://input has been changed a couple of times.

11 years ago by Park Framework — view source — reply

unread

Ok, i did a little test script, you can check, the browser sends to
the server a request body, but
var_dump(file_get_contents('php://input')) // string(0) ""

Do not forget to select a file to upload.

<?php
if($_SERVER['REQUEST_METHOD'] == 'POST')
{
var_dump(file_get_contents('php://input'));
exit;
}
?><html>

2014-10-16 0:14 GMT+03:00 Ralph Schindler ralph@ralphschindler.com:

I'm not sure I understand what you're trying to do, could you explain in
more detail with examples?

PUT /url
Content-type: application/x-www-form-urlencoded

parse_str (file_get_contents(‘php://input'), $_POST) // Ok

PUT /url
Content-type: multipart/mixed; boundary="xxxx"

file_get_contents(‘php://input') // Empty string

You are missing information in your example. First, PHP doesn't do content
negotiation for every Content-Type known to send serialized data, it is
extremely selective in that AFAIK, url/form encoded Content-Types, when
POSTed, will be content-negotiated, parsed, and their resultant will
populate the $_POST superglobal.

Moreover, your 2nd example does not suggest that an HTTP request was sent
with a body to demonstrate there is a bug here.

With a php script being served at index.php with the following contents:

<?php
var_dump(file_get_contents('php://input'));

Here is a demonstration of this script, and a successful read of the request
body:

$ echo 'FOOOO=BARRRRR' | http --verbose PUT localhost:8000
Content-Type:'multipart/mime; boundry=xxxxx'

PUT / HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Content-Length: 14
Content-Type: multipart/mime; boundry=xxxxx
Host: localhost:8000
User-Agent: HTTPie/0.8.0

FOOOO=BARRRRR

HTTP/1.1 200 OK
Connection: close
Content-type: text/html
Host: localhost:8000
X-Powered-By: PHP/5.5.15

string(14) "FOOOO=BARRRRR
"

-ralph

11 years ago by Stas Malyshev — view source — reply

unread

Hi!

<?php
if($_SERVER['REQUEST_METHOD'] == 'POST')
{
var_dump(file_get_contents('php://input'));
exit;
}

I tried this script, if you do POST, your data is in $_FILES, if you do
PUT, your data is in php://input. Still not sure what is the big problem.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

11 years ago by Park Framework — view source — reply

unread

2014-10-16 2:13 GMT+03:00 Stas Malyshev smalyshev@sugarcrm.com:

I tried this script, if you do POST, your data is in $_FILES, if you do
PUT, your data is in php://input. Still not sure what is the big problem.

I added the variable field, how do I get its value, with use the query
method PUT and enctype="multipart/form-data"?

This debate not for tediousness, this is a real problem, if you want
to use the query method PUT and enctype="multipart/form-data",
variable $_POST is empty and file_get_contents('php://input') is empty

<?php
if($_SERVER['REQUEST_METHOD'] == 'POST')
{
var_dump(file_get_contents('php://input'));
exit;
}
?><html>

<body> <form method="POST" enctype="multipart/form-data"> <input type="hidden" name="key" value="value"> <input type="file" name="file"> <hr> <button>POST</button> </form> </body> </html

11 years ago by Stas Malyshev — view source — reply

unread

Hi!

I added the variable field, how do I get its value, with use the query
method PUT and enctype="multipart/form-data"?

This debate not for tediousness, this is a real problem, if you want
to use the query method PUT and enctype="multipart/form-data",
variable $_POST is empty and file_get_contents('php://input') is empty

No, file_get_contents('php://input') is not empty - I just checked it
and if you send PUT request the whole request - files and all - is in
the php://input. If you don't see it you might be doing something wrong.

You are talking about PUT, but post example about POST for the second
time. I'm not sure what you mean by that as certainly your script does
not demonstrate what you are saying.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

11 years ago by Park Framework — view source — reply

unread

2014-10-16 2:36 GMT+03:00 Stas Malyshev smalyshev@sugarcrm.com:

No, file_get_contents('php://input') is not empty - I just checked it
and if you send PUT request the whole request - files and all - is in
the php://input. If you don't see it you might be doing something wrong.

Yes, you're right, I'm wrong tests, send PUT
enctype="multipart/form-data" - php://input - is not empty, sorry.

But parse multi part in the PHP script is not very good solution, can
use pecl-ext HTTP, but it is better if there are an global array of
$_BODY.

11 years ago by Dave — view source — reply

unread

there's really nothing missing from PHP today to enable successful & easy
implementation of RESTful interfaces.

Zeev,

I could not create a REST interface that accepted "multipart form data" in
uploading a file and form data in one PUT request.
This is a valid part of a RESTful interface, yet PHP does not provide
parsed data and file data for PUT like it does for POST (in the form of
$_FILES and $_POST).

The only way to do this in PHP now is write a userland function that parses
multipart form data, which is non-trivial. I had written one, but would
rather rely on the more-well tested parser which exists in PHP itself for
POST. (A side-note: in my case it was deemed less risky to employ a
load-balancer hack instead).

Having the ability to access the data provided in $_POST for other methods
is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc).

Dave.

Personally, I like the idea of using more appropriately named aliases,
particularly if they're roughly the same number of characters. However,
we
would need to allow at least several years for people to adopt the new
globals before deprecating $_GET and $_POST. Ultimately, they will
either
need to be deprecated or the $_PUT and $_DELETE aliases will need to be
added, otherwise the issue I raised would remain unresolved.

Kris,

Don't get this the wrong way, but $_GET and $_POST are not going to be
deprecated.

Whether or not we need $_PUT or $_DELETE is a separate, independent
question
from the axiom that $_GET and $_POST are here to stay. Personally, I don't
think they make sense as Rasmus pointed out that $_GET and $_POST were
never
about HTTP methods but form methods, and there's really nothing missing
from
PHP today to enable successful & easy implementation of RESTful interfaces.

Zeev

11 years ago by Sanford Whiteman — view source — reply

unread

The only way to do this in PHP now is write a userland function that parses
multipart form data, which is non-trivial.

In addition to PECL HTTP, you might try PECL Mailparse, which is also
going to be better-tested than anything written in userland.

I sympathize with your overall point: even without a new superglobal,
it would be cool to be able to reuse the same parser from $_POST.

Still, just to put this out there: receiving multiparts via PUT can be
part of a legit RESTful interface, but that doesn't mean that decoding
multiparts should be automatic. It shouldn't be surprising that it PHP
treats the entity as an opaque block of data by default, since it's
perfectly RESTful for the MIME-encoded body to be the stored
resource. Imagine an e-mail archive that PUTs to
/user/$username/sent/$messageid. Decoding the MIME message on
resource create/update would be inappropriate in that case, a huge
waste of resources. You might lazy-decode the resource only upon GET
/user/$username/sent/$messageid/part/1. Within the same installation,
you might want to decode other PUTs upon upload, so having a simple
on/off for a new superglobal wouldn't work.

-- S.

11 years ago by Stas Malyshev — view source — reply

unread

Hi!

The only way to do this in PHP now is write a userland function that parses
multipart form data, which is non-trivial. I had written one, but would

It is true that PUT data need to be parsed, however it is not true you
have to implement MIME parsing from scratch. There are frameworks that
implement that. Not everything must be written in C. But if you want C,
doesn't pecl/http already have the required bits?

Having the ability to access the data provided in $_POST for other methods
is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc).

There are a lot of HTTP verbs - PUT, DELETE, TRACE, PATCH... And what if
you want to do WebDAV? Wouldn't having separate superglobal for each be
taking it a bit too far?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

11 years ago by Florian Margaine — view source — reply

unread

Hi!

On Sun, Oct 26, 2014 at 10:21 PM, Stas Malyshev smalyshev@sugarcrm.com
wrote:

Hi!

The only way to do this in PHP now is write a userland function that
parses
multipart form data, which is non-trivial. I had written one, but would

It is true that PUT data need to be parsed, however it is not true you
have to implement MIME parsing from scratch. There are frameworks that
implement that. Not everything must be written in C. But if you want C,
doesn't pecl/http already have the required bits?

Having the ability to access the data provided in $_POST for other
methods
is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc).

There are a lot of HTTP verbs - PUT, DELETE, TRACE, PATCH... And what if
you want to do WebDAV? Wouldn't having separate superglobal for each be
taking it a bit too far?

I think Rasmus made it clear what the original naming meant: it were form
methods, not related at all to HTTP methods.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

--

Regards,

Florian Margaine

11 years ago by Park Framework — view source — reply

unread

2014-10-26 23:24 GMT+02:00 Florian Margaine florian@margaine.com:

I think Rasmus made it clear what the original naming meant: it were form
methods, not related at all to HTTP methods.

Yes, this would be logical to have access to the input data, as single
interface, do not make exceptions for POST, input data send methods
PUT, DELETE, must be available in a single global variable, the
variable name is not important
file_get_contents(‘php://input') - uncomfortably

11 years ago by Will Fitch — view source — reply

unread

2014-10-26 23:24 GMT+02:00 Florian Margaine florian@margaine.com:

I think Rasmus made it clear what the original naming meant: it were form
methods, not related at all to HTTP methods.

Yes, this would be logical to have access to the input data, as single
interface, do not make exceptions for POST, input data send methods
PUT, DELETE, must be available in a single global variable, the
variable name is not important
file_get_contents(‘php://input') - uncomfortably

Or, use pecl/http to handle it. GET/POST are form relative while all others are HTTP related. That’s been said quite a few times in this thread. You don’t have to use php://input php://input. pecl/http is available.

11 years ago by Sanford Whiteman — view source — reply

unread

pecl/http is available

To a degree, but no binaries for Windows == not a universal
prescription. Mailparse by contrast does have a shipping DLL.

-- S.

11 years ago by Will Fitch — view source — reply

unread

pecl/http is available

To a degree, but no binaries for Windows == not a universal
prescription. Mailparse by contrast does have a shipping DLL.

I’m confused. pecl/http does have Windows binaries: http://windows.php.net/downloads/pecl/releases/http/ http://windows.php.net/downloads/pecl/releases/http/. Did I miss something?

-- S.

11 years ago by Sanford Whiteman — view source — reply

unread

You're right. Guess the build system didn't update
http://pecl.php.net/package/pecl_http with the DLL link as for other
exts.

-- S,

On Oct 26, 2014, at 10:38 PM, Sanford Whiteman figureonecpr@gmail.com
wrote:

pecl/http is available

To a degree, but no binaries for Windows == not a universal
prescription. Mailparse by contrast does have a shipping DLL.

I’m confused. pecl/http does have Windows binaries:
http://windows.php.net/downloads/pecl/releases/http/. Did I miss something?

-- S.

11 years ago by Sanford Whiteman — view source — reply

unread

PUT, DELETE, must be available in a single global variable, the
variable name is not important
file_get_contents(‘php://input') - uncomfortably

If the quibble were with file_get_contents(‘php://input') that's not
sufficiently uncomfortable to warrant a new superglobal. I assume you
mean parsing the contents of php://input into an associative array
regardless of the content-type of the HTTP entity-body. However,
you're glossing over the semantic difference between POSTing an
entity-body and PUTing that same body.

multipart/form-data is specified in RFC 1867 as POST-specific, with
deliberate notes about expected server behavior. RFC 2388 expands
form-data into a general mimetype regardless of transport, and
theoretically regardless of HTTP method, but AFAIK there's no
equivalent to 1867 that reasonably leads to auto-decoding PUT
form-data into an associative array. Rather, the PUT payload has
always been designed to become the target resource, as-is. The POST
payload is designed to be interpreted via the server's own semantics
before changing any resource state. Thus there is a very strong reason
to present POST data to the server in an easily accessible and mutable
form. Not so for PUT.

This doesn't mean PUT payloads must stay opaque to PHP, of course. If
there's a need to validate the payload before overwriting the current
resource state, that may require that it be passed through some binary
image verification, validated against a DTD, or -- indeed -- decoded
from multipart MIME into its parts for validation, even if it's the
multipart representation that eventually gets stored. Yet if you feel
that PUT content should be automatically decoded, you might as well
apply this to other multipart content as well -- if I PUT an MHTML
file or, as noted before, an RFC 822 e-mail, by this assumption those
would also populate the new superglobal. Honestly if it didn't
consume any extra resources to always populate, I wouldn't care. But
to be unable to avoid decoding every giant multipart payload just
because I might want to look at the parts is highly inefficient.

-- S.

11 years ago by Will Fitch — view source — reply

unread

Hi!

The only way to do this in PHP now is write a userland function that parses
multipart form data, which is non-trivial. I had written one, but would

It is true that PUT data need to be parsed, however it is not true you
have to implement MIME parsing from scratch. There are frameworks that
implement that. Not everything must be written in C. But if you want C,
doesn't pecl/http already have the required bits?

100% agree. Perhaps focusing on getting pecl/http v2 added as ext or core should be the real discussion: https://wiki.php.net/rfc/pecl_http https://wiki.php.net/rfc/pecl_http.

Having the ability to access the data provided in $_POST for other methods
is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc).

There are a lot of HTTP verbs - PUT, DELETE, TRACE, PATCH... And what if
you want to do WebDAV? Wouldn't having separate superglobal for each be
taking it a bit too far?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

11 years ago by Ben Ramsey — view source — reply

unread

100% agree. Perhaps focusing on getting pecl/http v2 added as ext or core should be the real discussion: https://wiki.php.net/rfc/pecl_http https://wiki.php.net/rfc/pecl_http.

I would be supportive of this, and I’ll even volunteer to help make this happen with a v2 that adheres to the PHP-FIG’s PSR-7 proposal.

-Ben

11 years ago by Michael Wallner — view source — reply

unread

100% agree. Perhaps focusing on getting pecl/http v2 added as ext
or core should be the real discussion:
https://wiki.php.net/rfc/pecl_http
https://wiki.php.net/rfc/pecl_http.

I would be supportive of this, and I’ll even volunteer to help make
this happen with a v2 that adheres to the PHP-FIG’s PSR-7 proposal.

This already is v2, and PHP-FIG has been, well, I don't know how to call
that, dismissive(?) about the invitation to discuss.

Anyway, there's not been a single question since the RFC announcement,
except about the dependencies, so either nobody is interested, or those
who use it are fine with it.

--
Regards,
Mike

11 years ago by Larry Garfield — view source — reply

unread

100% agree. Perhaps focusing on getting pecl/http v2 added as ext
or core should be the real discussion:
https://wiki.php.net/rfc/pecl_http
https://wiki.php.net/rfc/pecl_http.

I would be supportive of this, and I’ll even volunteer to help make
this happen with a v2 that adheres to the PHP-FIG’s PSR-7 proposal.

This already is v2, and PHP-FIG has been, well, I don't know how to call
that, dismissive(?) about the invitation to discuss.

We have? FIG's been discussing PSR-7 a lot lately. :-) You're welcome
to join in. Our general stance is that request information should be
read from an object, not a superglobal, though.

--Larry Garfield

11 years ago by Michael Wallner — view source — reply

unread

Hi!

The only way to do this in PHP now is write a userland function that parses
multipart form data, which is non-trivial. I had written one, but would

It is true that PUT data need to be parsed, however it is not true you
have to implement MIME parsing from scratch. There are frameworks that
implement that. Not everything must be written in C. But if you want C,
doesn't pecl/http already have the required bits?

Yes, see here:

http://devel-m6w6.rhcloud.com/mdref/http/Env
http://devel-m6w6.rhcloud.com/mdref/http/Env/Request
http://devel-m6w6.rhcloud.com/mdref/http/Message
http://devel-m6w6.rhcloud.com/mdref/http/Message/splitMultipartBody
http://devel-m6w6.rhcloud.com/mdref/http/Message/Body

--
Regards,
Mike

11 years ago by Dave — view source — reply

unread

Sure, but the frustrating thing is that the C code (for mime-parsing) is
already there and just not being used for non-POST methods. Why make
everyone use pecl/framework code that duplicates what exists in PHP already
(albeit for POST only)?
You're right. That would be too many. That's why adding a single new
variable of $_FORM/BODY/foo would work for everything (including POST). Of
course, $_FILES (whose name is already method-agnostic) should be populated
too and not restricted to POST only.

Hi!

The only way to do this in PHP now is write a userland function that
parses
multipart form data, which is non-trivial. I had written one, but would

It is true that PUT data need to be parsed, however it is not true you
have to implement MIME parsing from scratch. There are frameworks that
implement that. Not everything must be written in C. But if you want C,
doesn't pecl/http already have the required bits?

Having the ability to access the data provided in $_POST for other
methods
is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc).

There are a lot of HTTP verbs - PUT, DELETE, TRACE, PATCH... And what if
you want to do WebDAV? Wouldn't having separate superglobal for each be
taking it a bit too far?

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/

11 years ago by Sanford Whiteman — view source — reply

unread

$_FILES (whose name is already method-agnostic)

The name appears method-agnostic but the implementation obviously
isn't. It works with multipart/form-data, which is tightly coupled
with POST, but which isn't the only way to transfer files, not by a
long shot. If you ignore the HTTP method you're being completely
arbitrary if you still only decode form-data into $_FILES. For
example we PUT and POST bytearray/binary files thousands of times per
day. You can PUT application/xml as a valid file, heck, you can PUT a
tarball, a great way to send multiple files. Would the enhanced
$_FILES be populated in those cases? And if not, why not?

-- S.

11 years ago by Rowan Collins — view source — reply

unread

I think 20+ years of history has proven this to be a non-issue. Of all
the things that people get confused by in PHP, $_GET/$_POST are right
near the bottom of the list.
The popularity of REST is what has changed this. Until people started
writing RESTful APIs, only two HTTP request types were in common use.
Nobody was confused about where PUT method data would end up, because
nobody processed any PUT methods.

It makes no sense to me to make $_BODY an alias for $_POST. $_POST
implies the default body encoding that a broswer performs on a POST
request. Making an alias called $_BODY that doesn't contain the body of
a request unless it is "POST"-encoded would be super confusing.
The encoding has no relationship with the request type, even in browsers

the default encoding of a POST form is actually the same encoding used
to produce a URL form a GET form.
Sure, but $_GET/$_POST do. They were not named to match HTTP primitives.
They were named to match form methods. As in form method="get" and
method="post". And here the default encoding the browsers use for these
two methods definitely matter.

Like, I say, application/x-www-form-urlencoded is the default encoding
for both method="get" and method="post". The difference is that one
executes an HTTP GET, and appends the encoded data to the request URL,
while the other executes an HTTP POST, and encloses the encoded data as
the request body.

Even coming from a browser form, both $_GET and $_POST can be populated
simultaneously, with independent data:

--
Rowan Collins
[IMSoP]

11 years ago by Rowan Collins — view source — reply

unread

I think 20+ years of history has proven this to be a non-issue. Of all
the things that people get confused by in PHP, $_GET/$_POST are right
near the bottom of the list.
The popularity of REST is what has changed this. Until people started
writing RESTful APIs, only two HTTP request types were in common use.
Nobody was confused about where PUT method data would end up, because
nobody processed any PUT methods.

It makes no sense to me to make $_BODY an alias for $_POST. $_POST
implies the default body encoding that a broswer performs on a POST
request. Making an alias called $_BODY that doesn't contain the
body of
a request unless it is "POST"-encoded would be super confusing.
The encoding has no relationship with the request type, even in
browsers

the default encoding of a POST form is actually the same encoding
used
to produce a URL form a GET form.
Sure, but $_GET/$_POST do. They were not named to match HTTP primitives.
They were named to match form methods. As in form method="get" and
method="post". And here the default encoding the browsers use for these
two methods definitely matter.

Like, I say, application/x-www-form-urlencoded is the default encoding
for both method="get" and method="post". The difference is that one
executes an HTTP GET, and appends the encoded data to the request URL,
while the other executes an HTTP POST, and encloses the encoded data
as the request body.

Even coming from a browser form, both $_GET and $_POST can be
populated simultaneously, with independent data:
<form method="post" action="/test.php?foo=query+data"><input type="hidden" name="foo" value="body data" /></form>

Actually, I think I misunderstood your post (insert bad pun here about
"I didn't get it") and should probably go to bed.

I think this thread is probably just repeating itself now anyway.

--
Rowan Collins
[IMSoP]

11 years ago by Zeev Suraski — view source — reply

unread

From: Rasmus Lerdorf [mailto:rasmus@lerdorf.com]
Sent: Tuesday, October 14, 2014 7:19 PM
To: Mike Dugan; Andrea Faulds; Kristopher
Cc: PHP internals list; Andrey Andreev; Kris Craig
Subject: Re: [PHP-DEV] New globals for PUT and DELETE

I think there was some misunderstanding of the usage of $_GET earlier
in this thread, although I may have misunderstood someone’s wording.
Regardless, if I go out and sample 100 PHP folks, I’m fairly confident
someone would make the association that either $_GET or $_POST is
bound strictly to the HTTP verb of the same name. Adding aliases gives
these vars a more semantic name while not causing a massive BC
breakage.

I think 20+ years of history has proven this to be a non-issue. Of all the
things
that people get confused by in PHP, $_GET/$_POST are right near the bottom
of the list.

11 years ago by Andrey Andreev — view source — reply

unread

Hi,

$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.

Ew, non-superglobals.

But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long:

$_QUERY - query string parameters

$_BODY - request body parameters

$_REQUEST - query string and request body parameters

Makes more sense than $_GET and $_POST.

Any objections?

It makes no sense to me to make $_BODY an alias for $_POST. $_POST
implies the default body encoding that a broswer performs on a POST
request. Making an alias called $_BODY that doesn't contain the body of
a request unless it is "POST"-encoded would be super confusing.

I think the pedantry level around this is rather high. Nobody is
actually confused about $_GET and $_POST and how and when to use them.
Adding vague aliases adds confusion to something that had no confusion
before.

-Rasmus

I agree ... in a strange way.

The pedantry level is indeed high, but being a pedant myself, I have
to point that confusion is the wrong word. It's misconception and
it is very widespread.

The vast majority of users, those who don't know PHP that well and
those who aren't familiar with the HTTP specification, do make a
direct relation between HTTP methods/verbs and the $_GET, $_POST
superglobals. The OP's proposition for $_PUT and $_DELETE here is
quite probably driven by the same perceived relation.

Most users see $_GET and then they see a GET/foo/bar HTTP/1.x request
and they think that's what it's all about. I haven't once heard from a
PHP developer in person to refer to $_GET as query parameters. To
them, it's "GET parameters".
They know that there's nothing in $_POST unless they submit their form
with method="post" and they believe that $_POST relates to POST
requests. In this case that's a more correct assumption, but still
missing the detail that Content-Type is important.

As a self-taught developer, I've gone through this myself. PHP had for
so long allowed me to build web applications without knowing how they
work at the low level and that was really, really great, but it also
tricked me into making the wrong assumptions.

All of the above aside however, I also don't think that aliasing to
$_QUERY and $_BODY or $_FORM would provide any real-world benefit.
We'd be lucky if people learn to only use the new "aliases" in 10
years ... not worth it given that we've dealt with $_POST and $_GET
for 20 years.
Populating $_POST with parsed payloads from other types of requests is
also not practical because RESTful services rarely use the
form-urlencoded format. And also because it would be further spreading
misconception, of course.

To address the misnomers, it's important to document that $_GET and
$_POST don't really represent GET and POST requests.

To aid the development of RESTful services, new and more appropriate
APIs should be provided. And we have to admit that there's a need for
that in the first place ...

json_decode(file_get_contents('php://input')) will work for many
people, but as somebody else already mentioned: there are other, more
structured subsets of JSON ... HAL was already mentioned, JSON-Patch
is another. What about XML and DTDs? Other formats?

Don't get me wrong, php://input is an awesome low-level solution. But
because we don't have a high-level one, it's also kind of: "Here, have
this thing and deal with it, we don't care if you really can."
So, to reiterate on my previous reply to this thread, what I think we
really need is to be able to register parsers at runtime, much like we
do with autoloaders. For example:

// Can't think of better function names right now ...
request_content_type_register($contentType, Callable $parser)
request_request_body(array &$assignParsedDataHere)

Of course ... input parsing should be done only once, so it's not
quite like with the spl_autoload queue, but I don't see an easier way
to deal with the problem.
Parsers for common formats such as application/json (depending on
available extensions) could be pre-registered, or not ... that's not
really important.

Cheers,
Andrey.

New globals for PUT and DELETE

Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and $_POST then. Because they’re aliases (by-reference superglobals), there’s no additional memory consumption, but we finally have saner names.

-- Lester Caine - G8HFL

That’s my idea, yes. They’d be implemented essentially as by-ref assignments internally.

So, we currently parse multipart and url-encoded request bodies for POST and put them in $_POST. I'm just thinking there's no good reason not to do so for any other request method. However, to avoid confusion, we alias it to $_FORM so it's clear it's not only for POST.

Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and $_POST then. Because they’re aliases (by-reference superglobals), there’s no additional memory consumption, but we finally have saner names.

I'm not sure I understand what you're trying to do, could you explain in more detail with examples?

I tried this script, if you do POST, your data is in $_FILES, if you do PUT, your data is in php://input. Still not sure what is the big problem.

Regards,

--
Lester Caine - G8HFL

Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET
and $_POST then. Because they’re aliases (by-reference superglobals),
there’s no additional memory consumption, but we finally have saner names.

I'm not sure I understand what you're trying to do, could you explain in
more detail with examples?

I tried this script, if you do POST, your data is in $_FILES, if you do
PUT, your data is in php://input. Still not sure what is the big problem.