Re: RFC: Server-Side Request and Response Objects (v2)

Hi Mike, Thanks for your continued evaluation of the RFC. > Take a look at WordPress. It does a lot of "fixup" to $_SERVER` variables — to > deal with badly implemented web servers — to ensure all known variables have a value and that the > format of the value is consistent. > > ... > > 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; class ServerRequestFactory { public function new(array $globals, ?string $content = null) : ServerRequest { // do fixup to $globals['_SERVER'] ... // ... then: return new ServerRequest($globals, $content); } } $request = (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. > > 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: > > $request->get('redirect', FILTER_SANITIZE_URL); > $request->get('product_id', FILTER_SANITIZE_NUMBER_INT); > $request->get('email', FILTER_SANITIZE_EMAIL); > > You could potentially even have scoped, easier to remember constants that can work with > autocomplete: > > $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.) >> >> That seems a bit much at this point. ;-) > > Really? Seems like this and some guard code is all it would take: > > 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. -- 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