Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78574
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.171 as permitted sender)
MIME-Version: 1.0
Sender: patrick.allaert@gmail.com
In-Reply-To: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
References: <CAL+t6cGt8B+X4ptWbyo6zm_xoyBOJC4QeiH6DjCxHX11CPWm_g@mail.gmail.com>
Date: Mon, 3 Nov 2014 13:08:11 +0100
Message-ID: <CACwt+JcYMS=+3t3e_JLHbNx-mgxUceiPOws2GZn9_QZ4HEo4Uw@mail.gmail.com>
To: Sherif Ramadan <theanomaly.is@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] New Standardized HTTP Interface
From: patrickallaert@php.net (Patrick ALLAERT)

2014-10-30 19:23 GMT+01:00 Sherif Ramadan <theanomaly.is@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