> On Feb 13, 2020, at 1:34 PM, Paul M. Jones <[email protected]> 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
