Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78121
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain daevel.net designates 178.32.94.222 as permitted sender)
Message-ID: <1413481197.3616.0.camel@daevel.net>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, Anthony Ferrara
 <ircmaxell@gmail.com>,  PHP Internals <internals@lists.php.net>
Date: Thu, 16 Oct 2014 19:39:57 +0200
In-Reply-To: <CAH-PCH65qUuZvzu6q6BF80O-peowgB2K9nAWDznEfgOTgcj7eg@mail.gmail.com>
References:
	  <CAAyV7nFciZcsL+AW9W4GbhM+PhM3RhWOJ7G0iBQsEHfSWO2QmA@mail.gmail.com>
	 <CAH-PCH6jVcXNtyySeY4EJZt2sQqhXFV=acO_x3HJb2f7WKtMPQ@mail.gmail.com>
	 <543FE883.2070401@lerdorf.com>
	 <CAH-PCH65qUuZvzu6q6BF80O-peowgB2K9nAWDznEfgOTgcj7eg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default
 for PDO_Mysql
From: php-dev.list@daevel.net (Olivier Bonvalet)

Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit :
> On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:
> 
> > On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
> > > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara <ircmaxell@gmail.com>
> > > wrote:
> > >
> > >> Hello all,
> > >>
> > >> I raised this topic on list over a year ago (
> > >> http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was
> > >> determined that it wasn't time yet to disable prepared statement
> > >> emulation for MySQL yet. However, Rasmus did mention that it was a
> > >> possibility for 5.4 (
> > >> http://marc.info/?l=php-internals&m=130418875017027&w=2 ). Since that
> > >> ship has sailed, I submitted a pull request for trunk to change the
> > >> default value of prepared statement emulation for MySQL.
> > >>
> > >> https://github.com/php/php-src/pull/108
> > >>
> > >> https://bugs.php.net/bug.php?id=54638
> > >>
> > >> Does this need to be an RFC (should I draft one)? Or can it just be
> > >> pulled as-is?
> > >>
> > >> Thanks,
> > >>
> > >> Anthony
> > >>
> > >> --
> > >> PHP Internals - PHP Runtime Development Mailing List
> > >> To unsubscribe, visit: http://www.php.net/unsub.php
> > >>
> > >>
> > > hi,
> > >
> > > do we want to change the default for this in PHP7?
> >
> > Honestly, I am not sure about this anymore. There is a significant
> > performance benefit in doing client-side prepares. Last year I attempted
> > to switch to server-side prepares on Etsy's production servers but it
> > added 30-40ms of page latency because of the extra round trips. And yes,
> > we were doing too many queries, but I fear if we change this default
> > people won't understand where this slowdown is coming from.
> >
> > Of course, in some rare cases using server-side prepares might speed
> > things up because of prepared statement caching in the server, but I
> > have yet to see a case where that caching outweighs the extra tcp
> > roundtrip overhead.
> >
> > I do agree that the default should probably be server-side since it is
> > the least surprising. We just need to make it very very clear in the
> > upgrade doc that this change will likely slow down peoples' apps and
> > show them how to turn client-side prepares back on.
> >
> > -Rasmus
> >
> 
> I don't think we should remove the option, just change the defaults, and
> most people would be fine switching back to the emulation, but it should be
> their conscious decision imo.
> Currently many people aren't aware that they are using client side
> prepares, and they are pretty much ignore the fact, that they can be
> exposed to sql injections (for example via using mismatching client and
> server encodings or not properly quoting the identifiers:
> http://www.codeyellow.nl/identifier-sqli.html because they think that
> server side prepared statements would be immune to this kind of problems).
> I think it would be better to change the default in a major version, if the
> tradeoff is performance vs security, and if they think that they are okay
> with the emulation, they can change it back.
> 
> 
> ps:
> don't forget that some/many of our users are still using php on a single
> server setup, where the mysql connection is done through a unix socket
> instead of the network stack, so the roundtrip there will be even less
> noticable, and usually those are the kind of users, who need safe defaults
> because they can't afford to be aware or change settings/code for their
> apps.
> 

Hi,

for me there is two usage of prepared statements : 
#1 : safely handle variables
#2 : performance in batch traitments

The first one want emulated prepared statments and the second need true
prepared.

It's possible to add a simplier method for the first one case, and let
prepare() do a true prepare by default.

For example here we extends PDO to add the q() shortcut.
This shortcut basicaly do that :

public function q($statement, array $params)
{
    $stmt = $this->prepare($statement, [PDO::MYSQL_ATTR_DIRECT_QUERY => true]);
    return $stmt->execute($params);
}