# [RFC Proposal] Introducing New Global Variable to Support Other HTTP Methods and Content Types - Thread: https://externals.io/message/97385 - Original archive: https://news-web.php.net/php.internals/97385 - Started by dejanstosic7@gmail.com on 2016-12-13T13:38:53+00:00 - Messages: 4 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #97385 — dejanstosic7@gmail.com — 2016-12-13T13:38:53+00:00 URL: https://externals.io/message/97385#97385 *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 --- ## #97387 — Rowan Collins — 2016-12-13T15:49:14+00:00 URL: https://externals.io/message/97385#97387 · In reply to: #97385 >*Disclaimer* >Sorry if this has been discussed before, i tried searching, but i >couldn't >find much information. It has, quite often actually. Here's a few threads I found in a quick search that look relevant: https://marc.info/?t=138003492500001&r=1&w=2 https://marc.info/?t=141329101900006&r=1&w=2 https://marc.info/?t=144226586800002&r=1&w=2 https://marc.info/?t=140822909300001&r=1&w=2 https://marc.info/?t=138069733000002&r=1&w=2 https://marc.info/?t=134822559800006&r=1&w=2 >*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). This isn't actually true. Despite the names, $_GET and $_POST don't actually have anything to do with the HTTP request verb. One tokenises the URL's "query string", and the other the request body. For a GET request, there is no body to parse, but for a POST request, it's perfectly normal for both to be populated. >Additionally it will parse the data only for >*application/x-www-form-urlencoded* or *multipart/form-data *HTTP >Content >types. This much is true, but as you'll see from previous discussions, it's not entirely clear how to usefully extend it. If we hard code the rules (e.g. the options json_decode offers) we limit people's options. If we give a pluggable interface, people might as well just parse the raw input themselves. Basically, you're not the first to think "some kind of support" is needed, but as yet nobody has come up with a compelling description of just what that support should look like. However, don't let that discourage you. If you do a bit more digging into the archives to understand the challenges, maybe you can come up with a new take on the idea. Regards, -- Rowan Collins [IMSoP] --- ## #97388 — Larry Garfield — 2016-12-13T16:51:21+00:00 URL: https://externals.io/message/97385#97388 · In reply to: #97385 > *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 --- ## #97391 — Michael Wallner — 2016-12-13T19:25:55+00:00 URL: https://externals.io/message/97385#97391 · In reply to: #97385 Am 13.12.2016 14:45 schrieb "Dejan Stošić" : *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)? Have a look at http://pecl.php.net/apfd which triggers the request body parser on any request method. Also, http://pecl.php.net/json_post provides a content type handler for JSON. Parsing of the request body happens before entering userland, so providing a pluggable interface (to userland) is not an option currently. Cheers, Mike Thanks