Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit :
> On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
>
> > On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
> > > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara <ircmax...@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);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
