Me as a user and developer PHP RESTful, enough auto filling the global variable. Make an abstract variable names (_BODY or _FORM), and filled with the value in all the HTTP methods.
Perhaps it makes sense to do lazy loading of data in these variables, it is simply done through an ArrayAccess interface to $_FORM variables were the objects that implement the interface to access an array when you first access the Elements massif, to parse HTTP message body Your effort is better spent on creating an interface of the PHP as a demon when Launched PHP script handles the HTTP requests. 2014-11-06 0:29 GMT+02:00 Sherif Ramadan <theanomaly...@gmail.com>: > I'm not keen on the idea of adding more superglobals to PHP, although I > certainly understand the grave concern of breaking people's code and as > such I've chosen not to pursue the idea of removing superglobals. > > I will, however, revisit the idea of exposing the underlying SAPI > callbacks, for handling the incoming HTTP request in PHP, to userland. From > a rough skim through the code, so far, it appears that this is already > entirely possible and shouldn't be very difficult to expose the SAPI API to > userland without breaking BC. This would make it possible for people to > register request handlers in the same way they can register autoloaders and > as such make it possible to handle things like PUT/MOVE/PROP FIND HTTP > requests through some custom callback. > > The only concern there is would people prefer to use their own custom > callbacks in userland or would they prefer for PHP to do it for them? > > From all the people I've spoken with that have a problem with handling PUT > requests in PHP, it seems that they'd rather have PHP populate > $_FILES/$_POST automatically in this case. Which would be relatively easy > to do by modifying the default post reader function in the SAPI > http://lxr.php.net/xref/PHP_5_6/main/php_content_types.c#51 however, that > is itself a small BC break. > > Does anyone have any recommendations on what they think the best approach > is? I'd appreciate any feedback/suggestions/constructive-criticism. Thanks! > > > > On Mon, Nov 3, 2014 at 7:08 AM, Patrick ALLAERT <patrickalla...@php.net> > wrote: > > > 2014-10-30 19:23 GMT+01:00 Sherif Ramadan <theanomaly...@gmail.com>: > > > Hello Internals, > > > > > > I've been meaning to write up a full-blown RFC for introducing a new > > > standardized HTTP interface for PHP core for some time now. I figure > now > > > with PHP 7 on the road map this might be a good time to start this > > > discussion since it involves breaking some backwards compatibility that > > may > > > have been out of the question in PHP 5. > > > > > > I've started a draft RFC, but please be patient as this is a working in > > > progress, here https://wiki.php.net/rfc/http-interface on the wiki. > > > > > > The point here is to allow users to implement their own HttpRequest and > > > HttpResponse classes that can deal directly with the raw > request/response > > > messages in any way the user deems fit. This alleviates cases like > "what > > > about when I want to have $_PUT or $_DELETE" and removes the ambiguity > of > > > the $_POST, $_GET superglobals to a more conforming way of handling the > > > messages. > > > > > > Since it's an interface, it only dictates the facilitation of PHP's > > > built-in functionality and the user's desired implementation, but no > the > > > implementation itself. To remove all confusion, consider the way an > HTTP > > > message actually looks. > > > > > > GET /foo?bar=1 HTTP/1.1 > > > Host: foobar.com > > > > > > baz=2 > > > > > > Instead of treating this with current $_GET, $_POST, let's consider > for a > > > moment how we might treat it in an HttpRequest object: > > > > > > If the HttpRequest class implements an HttpParameters object that > parses > > > and treats the entire HTTP request line as a string of parameters we > > could > > > accomplish the following... > > > > > > var_dump(HttpRequest::$parameters->bar); // int(1) > > > var_dump((string) HttpRequest::$parameters); // string(6)"?bar=1" > > > > > > Now consider how the body can be treated... > > > > > > echo HttpRequest::$body; // baz=2 > > > echo HttpRequest::$body->baz; // 2 > > > > > > Since the HttpRequest object can lazily parse the body it can also > lazily > > > apply custom filters directly to the request variables and > parameters... > > > > > > For example, say you wish to treat baz only as an integer? This can be > > > easily accomplished by setting the filters directly in the HttpRequest > > > object and upon access the filter is directly applied to chosen > > variables. > > > This also alleviates the need to worry about overwriting superglobal > > > variables or having to copy from them. So from an efficiency > stand-point > > > this approach works much better. It also allows you to separate clearly > > > between HTTP request parameters and HTTP request body as well as the > HTTP > > > request method. Since the request object should be capable of handling > > > callbacks for each method to apply different sets of filters or rules > on > > > treating the request body given different request methods this could > > prove > > > a lot more useful than existing techniques applied directly in PHP with > > > php://input, for example. > > > > > > We don't need to copy the internal stream and we don't need to modify > or > > > copy superglobals around to different parts of our code. > > > > > > I'm in the process of writing up a cleaner implementation to introduce > in > > > the RFC, but in the mean time I'd like to open up to discussion and see > > > what others think or how they feel we might approach this problem more > > > cleanly. > > > > > > Thanks, > > > Sherif > > > > I'm all for adding a standardized way of handling PHP's input in a OO > > way, however, no way we touch the existing super globals. > > I don't see the benefit of an *interface* and how you would interact > > with that with userland implementations. However, having simple and > > **immutable** objects on top of what already exists sounds interesting > > and reasonable. > > From the top of my head, something like: > > > > var_dump($_HTTP_REQUEST); > > > > object(PHP\HttpRequest)#1 (11) { > > ["protocol"]=> > > string(8) "HTTP/1.1" > > ["uri"]=> > > string(9) "/info.php" > > ["host"]=> > > string(11) "example.com" > > ["method"]=> > > string(3) "GET" > > ["port"]=> > > int(80) > > ["time"]=> > > float(1415015570.096) > > ["queryString"]=> > > string(11) "foo=1&bar=2" > > ["uriParams"]=> > > array(2) { > > ["foo"]=> > > int(1) > > ["bar"]=> > > int(2) > > } > > ["cookies"]=> > > array(1) { > > ["language"]=> > > string(2) "fr" > > } > > ["acceptEncoding"]=> > > array(3) { > > ["gzip"]=> > > bool(true) > > ["deflate"]=> > > bool(true) > > ["sdch"]=> > > bool(true) > > } > > ["userAgent"]=> > > string(105) "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 > > (KHTML, like Gecko) Chrome/38.0.2125.101 Safari/537.36" > > } > > > > Note that super globals are created on demand, so there is no impact > > on keeping $_GET, $_POST, ... variables aside a new OO implementation > > which should also benefit from this lazy loading mechanism. > > > > Patrick > > >
