Re: RFC: Server-Side Request and Response Objects (v2)
| From: | Paul M. Jones | Date: | Mon, 16 Mar 2020 15:00:32 +0000 |
| Subject: | Re: RFC: Server-Side Request and Response Objects (v2) | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-109061@lists.php.net to get a copy of this message | ||
Hi all,
That escalated quickly. :-) I'm going to reply to the only request for clarification I could
identify in this exchange -- if I missed others, please let me know.
>> Is the proposal really suggesting that a developer would still need to do
>>
if(!empty($request->server[‘HTTPS’]) &&
>> $request->server[‘HTTPS’] !== ‘off’) {…} rather than just providing a
>> secureTransport property (or https
>> if you prefer)?
>
> Not sure. Paul needs to answer that.
This is another one of those places where several of the individual projects have something similar,
but not close-enough to each other to represent it in the ServerRequest object. Some honor
'1' as 'on', some do not, etc.
So, yes, I'm saying that existing code using $_SERVER could use this as a replacement:
$secure = ($request->server['HTTPS'] ?? null) === 'on';
I'm open to discussion about additions to the object for this or other purposes, though, if we
can decide on "the right way" to calculate new proposed values.
--
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