RE: [PHP-DEV] Coercive STH - some real world tests and updated RFC

> -----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 number of URIs that 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 int type hint > because 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 simply 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