Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108548 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 77103 invoked from network); 13 Feb 2020 20:20:29 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Feb 2020 20:20:29 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id B8FD21804D1 for ; Thu, 13 Feb 2020 10:34:56 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS29169 217.70.176.0/20 X-Spam-Virus: No X-Envelope-From: Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 13 Feb 2020 10:34:55 -0800 (PST) X-Originating-IP: 107.223.28.39 Received: from samurai.attlocal.net (107-223-28-39.lightspeed.nsvltn.sbcglobal.net [107.223.28.39]) (Authenticated sender: pmjones@pmjones.io) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id 45593FF807; Thu, 13 Feb 2020 18:34:52 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) In-Reply-To: Date: Thu, 13 Feb 2020 12:34:51 -0600 Cc: internals@lists.php.net Content-Transfer-Encoding: quoted-printable Message-ID: References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io> <5DEE5A6E-2587-432D-9651-320DF42A7732@newclarity.net> To: Mike Schinkel X-Mailer: Apple Mail (2.3608.60.0.2.5) Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2) From: pmjones@pmjones.io ("Paul M. Jones") Hi Mike, Thanks for your continued evaluation of the RFC. > Take a look at WordPress. It does a lot of "fixup" to $_SERVER` = variables =E2=80=94 to deal with badly implemented web servers =E2=80=94 = to ensure all known variables have a value and that the format of the = value is consistent. =20 >=20 > ... >=20 > Another option actually would be to allow changes to $_SERVER prior to = instantiating ServerRequest() the first time. Believe it or not, this RFC does make allowance for what you're = describing, as a result of requiring a $globals array as the first = parameter. An application-specific builder or factory can modify those = $globals values as desired, before instantiating ServerRequest with the = modified values. For example: namespace App; use ServerRequest; =20 class ServerRequestFactory { public function new(array $globals, ?string $content =3D null) : = ServerRequest { // do fixup to $globals['_SERVER'] ... // ... then: return new ServerRequest($globals, $content); } } $request =3D (new \App\ServerRequestFactory())->new($GLOBALS); I can easily imagine many ways to achieve the same end (i.e., = modification of the constructor arguments before instantiating = ServerRequest). Do you get where I'm coming from? >> First, I'd have to decline adding request() (or $request) at all; my = opinion is that one ought to be reading from $get, $post, $cookies, etc. = specifically, not from a pool of those values. >=20 > That's definitely fair. I almost did not include request() in my = suggestion but did because PHP has $_REQUEST. Good enough. :-) > Why a method is important is to support filters (I guess I assumed = that was obvious but realize now it was not.) For example: >=20 > $request->get('redirect', FILTER_SANITIZE_URL); > $request->get('product_id', FILTER_SANITIZE_NUMBER_INT); > $request->get('email', FILTER_SANITIZE_EMAIL); >=20 > You could potentially even have scoped, easier to remember constants = that can work with autocomplete: >=20 > $request->get('redirect', ServerRequest::URL); > $request->get('product_id', ServerRequest::INT); > $request->get('email', ServerRequest::EMAIL); [snip] I do see what you mean. Even so, I think filtering is out-of-scope for = this RFC. Certainly I want to avoid adding methods to the ServerRequest = class, which as envisioned is a bag of values much the same way $_GET, = $_POST, $_SERVER, etc. are bags of values. >>> Would you not also add an option to generate a warning when using = them for those who want to deprecate their use in their own code = (deprecating across the board would be too extreme give how much CMS and = framework code uses them intimately.) >>=20 >> That seems a bit much at this point. ;-) >=20 > Really? Seems like this and some guard code is all it would take: >=20 > ini_set( "disallow_superglobals", true); Even if that's true (and I think that example masks some complexity) I = must maintain that it's out of scope for this RFC. --=20 Paul M. Jones pmjones@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php