Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78479
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain margaine.com from 209.85.223.176 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
Date: Thu, 30 Oct 2014 19:30:08 +0100
Message-ID: <CABRjmp9p=+zGiqn_nuVJcDAK0po98FnDhb7wTmG66tob4u0GOw@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113476981abf870506a813fb
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: florian@margaine.com (Florian Margaine)

--001a113476981abf870506a813fb
Content-Type: text/plain; charset=UTF-8

Hi,

On Thu, Oct 30, 2014 at 7:23 PM, Sherif Ramadan <theanomaly.is@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

--001a113476981abf870506a813fb--