Hi, On Thu, Oct 30, 2014 at 7:23 PM, Sherif Ramadan <theanomaly...@gmail.com> wrote:
> 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. I find this very... useless. Sure, interfaces are not useless. But I don't think php-src is there to dictate what userland code should look like. It should provide *implementations*, not interfaces. > 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 > The other thing I don't like in your RFC is the removal of superglobals. Sure, they're not the best interface out there, but breaking *every single* codebase out there is not the way to go. Especially if we don't want a perl6/python3-like failure to adoption. Regards, -- Florian Margaine
