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 >
