> On Feb 13, 2020, at 1:34 PM, Paul M. Jones <pmjo...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php