Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97387
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.196 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAO3At4_wASwLsjdb-mcb__792T5jpDv9TEAEA+k3uFhs_eQyVw@mail.gmail.com>
References: <CAO3At4_wASwLsjdb-mcb__792T5jpDv9TEAEA+k3uFhs_eQyVw@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Tue, 13 Dec 2016 15:49:14 +0000
To: =?UTF-8?Q?Dejan_Sto=C5=A1i=C4=87?= <dejanstosic7@gmail.com>,internals@lists.php.net
Message-ID: <DD43C285-E260-41E1-AD77-48C169C2F207@gmail.com>
Subject: Re: [PHP-DEV] [RFC Proposal] Introducing New Global Variable to Support Other HTTP Methods and Content Types
From: rowan.collins@gmail.com (Rowan Collins)

On 13 December 2016 13:38:53 GMT+00:00, "Dejan Stošić" <dejanstosic7@gmail.com> wrote:
>*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]