Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84152
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 74.125.82.177 as permitted sender)
References: <d238d736f8fcde9e649cb38c9b05fcc1@mail.gmail.com> <DUB113-W139512BB87516EAD168575DF9130@phx.gbl>
In-Reply-To: <DUB113-W139512BB87516EAD168575DF9130@phx.gbl>
MIME-Version: 1.0
Thread-Index: AQHbEgvqZ08kgCvmYfG4mXODzCFejgD7DxronOuIwPA=
Date: Mon, 2 Mar 2015 10:39:53 +0200
Message-ID: <ed4e3cf6c363aa74cdd44c7d908f5d3a@mail.gmail.com>
To: Thomas Punt <tpunt@hotmail.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Thomas Punt [mailto:tpunt@hotmail.co.uk]
> Sent: Sunday, March 01, 2015 4:03 PM
> To: Zeev Suraski; PHP internals
> Subject: RE: [PHP-DEV] Coercive STH - some real world tests and updated
> RFC
>
> Hey Zeev,
>
> > Another change being considered and not yet in the RFC is re-allowing
> > leading and trailing spaces for numeric strings (sorry Paddy.)
>
> I think that rejecting leading and trailing spaces for stringy ints is
for the best.
> If I only want to accept an integer (in either int or string form), then
by
> enabling spaces in that input, it would destroy the overall usability of
it.
>
> One scenario I have in mind for this is validating $_GET information for
a
> RESTful web service. Having potentially an infinite=C2=A0number of URIs t=
hat
all
> point to the same resource isn't good:
>
> /users/1
> /users/%201
> /users/1%20
> /users/%201%20
> /users/%201%20%20
> etc.
>
> In this case, I don't want to accept any leading or trailing spaces for
the user
> ID. So I would therefore not be able to use an=C2=A0`int` type hint becau=
se
its
> acceptance rules would be too lax.
>
> If spaces are not accepted in stringy ints, and I want to pass a stringy
int that
> may have leading or trailing spaces in it, then I know I can=C2=A0simply
apply a
> trim() to it before passing it into a function that's expecting only an
int. This
> way, the usability of integer-only inputs (as string or ints) isn't
compromised
> by the rules being too weak.

Tom,

First of all thanks for the feedback!  I think that with leading/trailing
spaces we could go either way.  It boils down to the question of whether
we want spaces to be explicitly trim()'d and have the rule-set more
restrictive, or have the rule-set more permissive - preventing some use
cases from using it and having to do manual validation instead.  Based on
the fact this has been a source of back & forth changes
(twitter.com/AndreaFaulds/status/570979956349665281), there's not going to
be a one size fits all rule-set here.  I think that the use cases where it
will be harmless to ignore leading/trailing spaces would be more common
than those where it's risky or undesired...

> > The takeaway from this seems to be that the approach of tightening the
> > existing rule-set and applying it to both internal functions and new
> > user-land code is viable, and does not cause the sky to come down
falling.
> > Preliminary tests suggest it actually finds real potential problems.
> >
> > More tomorrow.
>
> Overall, a big +1 on this though! The type coercion rules at the moment
are
> far too lax to be considered useful in most situations IMO.

Thanks for the feedback!

Zeev