Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100388 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36446 invoked from network); 5 Sep 2017 17:24:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Sep 2017 17:24:42 -0000 Authentication-Results: pb1.pair.com header.from=lists@rhsoft.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=lists@rhsoft.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain rhsoft.net designates 91.118.73.15 as permitted sender) X-PHP-List-Original-Sender: lists@rhsoft.net X-Host-Fingerprint: 91.118.73.15 mail.thelounge.net Received: from [91.118.73.15] ([91.118.73.15:38421] helo=mail.thelounge.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 79/D9-04538-8DDDEA95 for ; Tue, 05 Sep 2017 13:24:42 -0400 Received: from rh.thelounge.net (Authenticated sender: h.reindl@thelounge.net) by mail.thelounge.net (THELOUNGE MTA) with ESMTPSA id 3xmtr06M1DzXMd for ; Tue, 5 Sep 2017 19:24:32 +0200 (CEST) To: internals@lists.php.net References: <0C7F986C-B0BC-4315-98ED-B4FD003B9399@gmail.com> <2a4491b4-e6f5-4297-beec-363f373a93e6@lsces.co.uk> <3f8be7b1-0e59-21c6-4fe8-8299b2c05645@rhsoft.net> <6ba62d62-f1ab-9e7b-93f0-a1a9238c47a6@lsces.co.uk> Message-ID: <87fe6ba9-5192-ce21-650f-a6a9aaaa289d@rhsoft.net> Date: Tue, 5 Sep 2017 19:24:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <6ba62d62-f1ab-9e7b-93f0-a1a9238c47a6@lsces.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-CH Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] A validator module for PHP7 From: lists@rhsoft.net ("lists@rhsoft.net") Am 05.09.2017 um 18:57 schrieb Lester Caine: > But not at the cost of writing different sets of code to play to each > area where checking SHOULD be done. Stick to a single standard method of > defining the metadata and that already exists in the database layer ok, to make that point clear: not every input which needs to be validated or sanitized is *related to a database at all* and hence input validation can't be done in the database-layer and only there by definition for everything frankly since 3 weeks our core-application is at a level where the database-layer get not loaded at all until inputs are not verfified because database stuff is on-demand and 80% of all requests when there is some traffic within 80% seconds don't load the database layer because of smart caching form-input is validated, checked against CSRF-tokens, captcha and *after* all the validations are fine the database layer becomes part of the game - that alone brought again 43% higher requests/second on a already highly optimizied codebase