Re: HTTP supergloblas and request body/query (was: Parsing PUT data)
| From: | Leigh | Date: | Wed, 02 Oct 2013 11:12:08 +0000 |
| Subject: | Re: HTTP supergloblas and request body/query (was: Parsing PUT data) | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-69446@lists.php.net to get a copy of this message | ||
On 2 October 2013 07:59, Michael Wallner <mike@php.net> wrote:
> I propose to phase out $_GET and name it $_QUERY and
> I propose to phase out $_POST and name it $_FORM
I have to say I'm against this aspect of the proposal. While the names
may not be 100% accurate, _most_ people are used to their behaviour.
You certainly won't be able to remove $_GET / $_POST (implied by
"phase out") in any 5.x release, it's just too big of a BC break.
> Further, I propose to remove the POST method restriction for handling
> request bodies and solely rely on the content type to trigger the
> parser(s). (*)
This makes more sense, HTTP/1.1 spec states all methods (except TRACE)
are allowed a body. This is where it could get pretty confusing
though, since a GET is allowed a body that could populate $_POST. I
still don't think it justifies the name change though.
On 2 October 2013 08:31, Michael Wallner <mike@php.net> wrote:
>
> I had it, but I'm not sure $_BODY fits either, because it should be an
> array. Currently only form data fits the purpose of de-serialisation
> of a request body.
>
Not so sure about that. I don't think there is a rule that says a body
_has_ to be in query string name=value format, or that multipart
elements _have_ to have a name=something attribute. I could quite
easily imagine PUT requests containing a textual body without an
associated field name (the URI would contain the field name).
(correct me if I'm wrong)