Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118761
MIME-Version: 1.0
References: <CAGBsUrdri=hXQHy5JnVhpiz51FbnqVBHjrBg9-tj8m=vzfZtzA@mail.gmail.com>
 <0cfb9a7b-1168-42ef-ae1a-bdc72210de43@app.fastmail.com> <CA+p1FaaDimmXXxfmGYogENvTpKp2qvyYNt4MyJT9HrehiTbXGg@mail.gmail.com>
 <CAGgaK7LMx+hd_V_EPNnmRb8pggAmP62vVtLjh=xgCFCkCQ0dgw@mail.gmail.com>
 <CA+p1FaapMaiWzz438Jr7N6B5qg0FecUuzzoe5oce-PyggaSzXw@mail.gmail.com>
 <CANYPt=WE+iTbECh3Kzh+jqkkqz2+6ezG6PGpSKypJm0yGQhMCw@mail.gmail.com> <ef9896b7-eb66-b944-a2e8-ea0adb44abf2@gmail.com>
In-Reply-To: <ef9896b7-eb66-b944-a2e8-ea0adb44abf2@gmail.com>
Date: Wed, 5 Oct 2022 22:35:58 +0100
Message-ID: <CA+p1FaaeKQGFPVG2C_nYFp5Z07WupruMidmwaPjjJ=XG5rZWgQ@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000007544fc05ea505d19"
Subject: Re: [PHP-DEV] Sanitize filters
From: davidgebler@gmail.com (David Gebler)

--0000000000007544fc05ea505d19
Content-Type: text/plain; charset="UTF-8"

On Tue, Oct 4, 2022 at 11:34 AM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> The "notorious" thing I know is that validating e-mail addresses is next
> to impossible because of multiple overlapping standards, and a huge
> number of esoteric variations that might or might not actually be
> deliverable in practice. If you think the implementation can be
> improved, that doesn't need a new is_valid_email() function, just a
> tested and documented patch to the existing one; if it can't be
> improved, then any new function will be just as useless
>

There are multiple RFC standards for email address format but AFAIK PHP's
FILTER_SANITIZE_EMAIL doesn't conform to any of them.

The idea behind my suggestion for something like is_valid_email (whatever
it might be named) is as a step towards deprecating and removing the entire
existing filter API, which I think many of us agree is a mess. As you said
below "it's trying to be everything to everyone, and ends up with a
bewildering set of options" - a rewrite or replacement which also tries to
be everything to everyone won't solve that problem, but getting rid of it
entirely will.

That said, the nature of PHP as a web-first language means it's reasonable
to include some individual, smaller, better APIs for certain validations or
sanitizations on types of data which are very commonly encountered in HTTP
requests. Examples include strings we expect or want to be valid integers,
decimals, email addresses and URLs. I think these features should remain,
but I'd happily see them even as a set of new, individual core functions if
it meant binning off filter_var and filter_input in PHP 9.

Regardless, look - I don't want to derail here - if most people are happy
with just deprecating some of the crappier and more confusing sanitize
filters and leave it at that, I say great, go for it, it's still an
improvement. I'm just saying if someone's going to take the time to look at
that problem space, why not go more than half the distance and reconsider
the fundamental approach of something we all know is pretty sucky anyway?

Just food for thought.

--0000000000007544fc05ea505d19--