Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108627
To: internals@lists.php.net
References: <50BD013E-CF72-414C-BBC0-A7A2E45CBDDB@pmjones.io>
 <5DEE5A6E-2587-432D-9651-320DF42A7732@newclarity.net>
 <A988787C-9EB6-4BF2-90DF-68F0D3BAC494@pmjones.io>
 <DC294D91-AA70-45C4-A3A5-32454675F42A@newclarity.net>
 <D3BABA50-AE6A-4711-A595-878CA8A8175F@pmjones.io>
 <C0EED521-5C75-40F0-9723-2B6D5FFA799E@newclarity.net>
Message-ID: <52c24f76-570a-8541-1d62-555f2a0582f5@gmail.com>
Date: Sun, 16 Feb 2020 23:34:42 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <C0EED521-5C75-40F0-9723-2B6D5FFA799E@newclarity.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
From: rowan.collins@gmail.com (Rowan Tommins)

On 13/02/2020 20:31, Mike Schinkel wrote:
> 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.


I think you are over-estimating how central the filter API is to most 
people's workflow with requests. I think that's partly because designing 
a good validation API is hard, but also because filter_input in 
particular is a combination of three different concerns:

1) Fetching the raw information about the incoming HTTP request from the 
web server (the "SAPI")
2) Parsing that raw information into individual fields
3) Validating those fields against expected type constraints

The superglobals already combine concerns 1 and 2, and the filter API 
adds concern 3; but to do so they all assume that the user is basically 
writing a CGI wrapper for some HTML forms.

The modern reality is rather different, and step 2 in particular is much 
more variable:

- Rather than query string parameters, it might involve extracting 
parameters from an SEO URL like "/products/123-acme-thingummy" or a 
RESTish URL like "/products/123/description/en-GB"
- Rather than submitted form data, it might involve parsing JSON from an 
AJAX request or API call


I would love to see new APIs that take a step back from the legacy, and 
tackle each of these concerns separately, based on modern requirements.

For concern 1, getting data out of the web server, I'd love to see:

- A more intuitive way to get the raw request body than 
file_get_contents('php://input')
- A more reliable way to get the URL the user requested than checking 5 
different variables in $_SERVER to handle different deployment methods 
(see e.g. [1] and [2] for the lengths libraries go to for this)
- A proper distinction between HTTP headers, server status variables, 
and environment variables, because CGI name-mangling is legacy cruft 
that users shouldn't need to learn

For concern 2, parsing that data, I'd love to see:

- A better API than parse_str for parsing arbitrary strings in 
application/x-www-form-urlencoded format
- A way to parse data in multipart/form-data format decoupled from the 
current HTTP request
- Tools for working with Content-Type strings, such as a function for 
correctly parsing things like "text/html;charset=UTF-8", and constants 
for common MIME types

Concern 3, filtering / sanitising / validating, I think is a really hard 
problem space, and I don't think there will ever be one implementation 
that suits all cases.

A similar "shopping list" could probably be made for responses, but if 
we decoupled the pieces, we wouldn't have to perfect them all at once; 
instead, we could provide building blocks that make userland 
implementations easier.


[1] 
https://github.com/symfony/symfony/blob/9acb06041cc88b5c14d40f8cd9a74dd14d7ac786/src/Symfony/Component/HttpFoundation/Request.php#L1741
[2] 
https://github.com/laminas/laminas-diactoros/blob/b36d6bf376b03dfc3190b1065630090e57f2e20d/src/functions/marshal_uri_from_sapi.php

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]