Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94129 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 57102 invoked from network); 19 Jun 2016 17:15:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Jun 2016 17:15:05 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.230 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.230 mail4-3.serversure.net Linux 2.6 Received: from [217.147.176.230] ([217.147.176.230:53439] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D9/91-18862-613D6675 for ; Sun, 19 Jun 2016 13:15:03 -0400 Received: (qmail 11046 invoked by uid 89); 19 Jun 2016 17:14:59 -0000 Received: by simscan 1.3.1 ppid: 11039, pid: 11042, t: 0.0737s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 19 Jun 2016 17:14:59 -0000 To: internals@lists.php.net References: <20160617202344.2868F1A80C02@dd1730.kasserver.com> <57665E36.60302@lsces.co.uk> Message-ID: <5766D311.6030503@lsces.co.uk> Date: Sun, 19 Jun 2016 18:14:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] New escaped output operator From: lester@lsces.co.uk (Lester Caine) On 19/06/16 10:01, Marco Pivetta wrote: > This basically means that you lack basic understanding of how escaping and > user input are to be handled. > Most apps out there about getting a bunch of text from the user, then > rendering it somewhere else in the app. > Cleaning user input just leads to frustration and a big mess in most > scenarios, which is why we're all talking about escaping output instead. > This is not "cleaning" either, it's escaping, which is a non-destructive > and reversible operation (which is why it works so well). Well we have to disagree ... simply expecting htmlspecialchars() to fix all your problems without proper handling of the input text is 'the big mess' and there is NO need to simply slap htmlspecialchars() onto properly built data so the idea that