Re: [PHP-DEV] Native support - PUT request, multipart form data

On 08/17/2014 03:55 PM, Chris Wright wrote:
> On 17 August 2014 11:49, David Zuelke <[email protected]> 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