Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76680
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
Message-ID: <53F2C621.7050800@garfieldtech.com>
Date: Mon, 18 Aug 2014 22:36:01 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAPRqa+G7_quRQ-NR04DChPEZeevuRBHX_1GbOCO+N4VXnzrCTw@mail.gmail.com>	<CAGAGxbYjc7MAnKQBNB6hb6StsWaRMshxUZieebmoYXHeNmFGyw@mail.gmail.com>	<CAPRqa+Hu4dqCs3X7O+Kh3A15eRQG-savV+2i-R=A3VGp-t6fxA@mail.gmail.com>	<20140817021822.9AEBE261C47@dd15934.kasserver.com>	<DC15CB30-2B57-4FEF-A679-D82AE02A78F4@heroku.com> <CAGAGxbas-MHC0SVbgNTsYCdr2fQqKaUDax+TiCVDrE-h5wXGXw@mail.gmail.com>
In-Reply-To: <CAGAGxbas-MHC0SVbgNTsYCdr2fQqKaUDax+TiCVDrE-h5wXGXw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Native support - PUT request, multipart form data
From: larry@garfieldtech.com (Larry Garfield)

On 08/17/2014 03:55 PM, Chris Wright wrote:
> On 17 August 2014 11:49, David Zuelke <dz@heroku.com> wrote:
>> That does not make any sense; applications could accept XML, CSV or whatever else just as well.
>>
>> The original proposal is not very useful. $_GET contains parsed query string info, $_POST contains parsed HTTP request body information if the media type is application/x-www-urlencoded or multipart/form-data. Deserializing that makes sense as the rules for it are in the HTTP spec.
> (warning: nitpicking) actually, neither of these types are part of the
> HTTP specification, the protocol specification doesn't deal with how
> to handle content, only how to transmit it. RFC 2616 makes no mention
> of it, and RFCs 7230-7235 don't either.
>
>> $_PUT/$_BODY/$_DATA would then have to contain the raw body contents, at least if the media type isn't one of the above, for consistency. That'd saves the file_get_contents() call, and given how a request handler uses at most once, I'm not sure such a change is worth it.
> I completely agree that there should be no special processing in the
> case of any content-type that is not already handled by $_POST, but I
> don't see the harm in handling those content types for arbitrary
> methods.
>
> Personally my ideal option would be to deprecate $_POST and $_GET in
> favour of $_BODY and $_QUERY, respectively, which would be populated
> the same way regardless of the request method (not just PUT and POST).
> Similarly $_FILES would be populated for any multipart/form-data
> request entity, regardless of request method.
>
> No other content type could be reasonably handled since there is
> ambiguity in how it would be handled (to take the alternate examples
> David mentioned, json_decode() has options and there are a million and
> one ways to handle XML). One might suggest having these configurable
> with ini options or runtime functions, but both of these would largely
> defeat the purpose of such automatic handling.
>
> I agree with Julien that this is not the sort of thing that should go
> into a point release, and if $_POST/$_GET were to be deprecated then
> this would be a change for 7, probably with removal not before 8.
>
> All that said, I personally don't find the requirement for writing 2
> additional lines to parse the data such a huge burden. I'm not against
> it, but neither will I be particularly upset if it doesn't happen.

Related, PHP-FIG is working on a set of common request/response object 
interfaces.  The main hold up right now is stream handling for the body, 
driven mostly by how developer un-friendly the native PHP stream 
handling is.  Long-term I do believe that PHP should have support for 
such objects natively and deprecate the super-globals, but that is a 
non-trivial transition.

See also:

http://mtdowling.com/blog/2014/07/03/a-case-for-higher-level-php-streams/

And discussion thread here:
https://groups.google.com/d/msgid/php-fig/53D4542B.1080408%40garfieldtech.com

--Larry Garfield