On 12/13/2016 07:38 AM, Dejan Stošić wrote:
*Disclaimer*
Sorry if this has been discussed before, i tried searching, but i couldn't
find much information.
I probably have nowhere near the experience of you guys, so i apologize if
i overlooked something obvious. I'd like to hear if this is a good or a
terrible idea and the reasons behind it. I'm new to the world of core PHP
development, but if this makes sense, i could try working on this myself.
*Introduction*
The world of web dev has shifted a lot toward API development in the last
few years. Specifically - REST APIs are becoming the industry standard.
Among other things, one of the core principles of REST is to utilize all
HTTP methods - (GET, POST, PUT, PATCH, DELETE...).
*The problem*
Currently, PHP will parse the incoming HTTP request body only for GET
requests (and store the data in superglobal $_GET) and for POST requests
(and store the data in $_POST).
Additionally it will parse the data only for
*application/x-www-form-urlencoded* or *multipart/form-data *HTTP Content
types.
There are other 3rd party libraries and packages that enhance this and
enable parsing for other request methods and content types, but i feel like
this should have native support at this point.
*Goal*
Ideally, PHP should natively parse the incoming HTTP request body for all
request methods, not only for GET and POST. I guess that completely
replacing the $_POST and $_GET is out of the question as it would lead to
no backward compatibility. Maybe an additional superglobal could be
introduced ($_DATA)?
Thanks
This would be infeasible. Parse it how?
The $_GET and $_POST variables are really misnamed. $_GET is "URI query
parameters" (which have nothing to do with the body, and can be present
for any HTTP method) and $_POST is, as you note, "the request body
parsed according to x-www-form-urlencoded rules". If the content type
is something else, then we don't know how to parse it. We could make
educated guesses in some cases, but then how do you know which one to
guess? Is it a supported guess? That's a very deep rabbit hole.
Remember, just because a request is a POST doesn't mean it's
x-www.-form-urlencoded, and just because it's a PUT doesn't mean it isn't.
The better solution is what's already available: Read the input stream
directly and parse it yourself in user-space using whatever parser you
know to be appropriate for your application.
PSR-7 has a built-in mechanism for tracking and storing the parsed
result, but the actual parsing itself is up to you.
Besides all that, adding more global variables to the SAPI is just a
terrible idea in general as global variables are where architecture goes
to die.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
