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

> On Feb 13, 2020, at 1:34 PM, Paul M. Jones <pmjones@pmjones.io> wrote: > > 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? Ah, I see now. That does allow for changing. OTOH, what it does not do is ensure that everyone looking at the values are looking at the fixed-up values, nor does it offer any way to cache the original value except to do so at the top of every PHP file that is a URL endpoint. I was hoping that your proposal was having a way to capture the original values before any PHP code could change them AND also then allow for fixed-up values to be provided for _every_ instantiation of ServerRequest(). This in case a library were to use it, I would not want the library to be getting the non-fixed up values. So in that respect, this is worse than what we have now. >> 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. I would implore you to reconsider. Without incorporating the functionality of filter_input() you have effectively neutered much of the value I envision your RFC having. In the USA we might say "Besides that Mrs. Lincoln, how was the play?" If I had a vote I would vote I would enthusiastically vote for the RFC if it includes filter_input() functionality. But I would vote against this RFC if it omits filter_input() functionality because it would mean another subsystem in core that does not actually address day-to-day concerns. > 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. Unless I misunderstand avoiding methods in ServerRequest is an arbitrary constraint which has no real-world requirement. And if your motivation is to only mirror what exists then filter_input() is a function so an equivalent in ServerRequest should be a method and thus this in not inconsistent with your mirroring aspect. -Mike