Re: HTTP supergloblas and request body/query (was: Parsing PUT data)

Am 02.10.2013 23:40, schrieb Johannes Schlüter: > On Wed, 2013-10-02 at 19:59 +0200, Michael Wallner wrote: >> On 2 October 2013 16:10, Johannes Schlüter <johannes@schlueters.de> wrote: >> > On Wed, 2013-10-02 at 08:59 +0200, Michael Wallner wrote: >> >> Since ever people are confused by _GET and _POST superglobals, >> >> because, despite their name, they do not (really) depend on the >> >> request method. Therefor I propose to phase out $_GET and name it >> >> $_QUERY and I propose to phase out $_POST and name it $_FORM (I'm not >> >> 100% confident with the latter yet, though). >> > >> > The later is certainly misleading. The current naming corresponds to >> > HTML forms. >> > >> > <form method="GET"> -> $_GET >> > <form method="POST"> -> $_POST >> >> Heh, pretty good observation! Didn't think about that. Still not >> buying. $_FORM is derived from "application/x-www-form-urlencoded" >> resp. "multipart/form-data" and $_QUERY is obvious. > > Out of curiosity I did some browsing: > > - ASP uses Request.QueryString(string name) and Request.Form > - Java Servlets and JSP use ServletRequest.getParameter() for both > - Perl CGI.pm has a param hash for both. > > I didn't look really deep though for further specifics :) > > So, ASP seems to agree with you, while I see a e difference: In ASP > those are methods which, when used, are always qualified by the Request > Object's name. Actually I like the idea of having an API to handle everything important for the HTTP-request and respectively for the response. e. g.: HTTPRequest::getFormData(...), which could possibly be aliased by HTTPRequest::getPOSTData(...) or HTTPRequest::getPOST(...); as well as HTTPRequest::getQueryData(...) aliased by HTTPRequest::getGETData(...) or HTTPRequest::getGET(...); and HTTPRequest::filterXXX(...) as a replacement for filter_var() and so on HTTPResponse could include a replacement for htmlspecialchars and htmlentities (not quite sure, if this fits better to HTTPRequest or probably into both) HTTPResponse::buildQuery() would be a replacement für http_build_query and so on. To make a long story short: IMHO Every function and superglobal related to the HTTP-request or -response should be moved to their respective classes so eveything is under one hood rather than making userland guessing which function/superglobal/whatever is for what purpose. As it is now, it is kinda chaotic and confusing to me and probably to userland, too. Just may 2 cents about that topic. Regards, Christian Stadler