Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77984
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
Message-ID: <543D23F4.4010609@gmail.com>
Date: Tue, 14 Oct 2014 14:24:04 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAKOpQSwS=Xck41sQQyEYGG8L3VHq+fRWjy0dDorbwZaVWMLCow@mail.gmail.com>	<9CAD580B-48C1-4D91-B761-20F8A9804A66@benramsey.com> <CAKOpQSynzFJQc7uOwuV6-cSNtvW_78pVSxcNvpFqkauFBC0ZHA@mail.gmail.com>
In-Reply-To: <CAKOpQSynzFJQc7uOwuV6-cSNtvW_78pVSxcNvpFqkauFBC0ZHA@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------040309040804050102080603"
Subject: Re: [PHP-DEV] New globals for PUT and DELETE
From: rowan.collins@gmail.com (Rowan Collins)

--------------040309040804050102080603
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.

--------------040309040804050102080603--