| Re: is mysqli_real_escape_string bullet proof with binary data? [message #182310 is a reply to message #182305] |
Sun, 28 July 2013 01:55   |
Pierre Jaury
Messages: 5
Registered: July 2013
Karma:
|
Junior Member |
|
|
Jerry Stuckle <jstucklex(at)attglobal(dot)net> writes:
> On 7/27/2013 4:25 PM, Pierre Jaury wrote:
>> Denis McMahon <denismfmcmahon(at)gmail(dot)com> writes:
>>
>>> On Sat, 27 Jul 2013 11:45:50 +0200, Luuk wrote:
>>>
>>>> On 27-07-2013 11:31, The Natural Philosopher wrote:
>>>
>>>> > The target is to create and store thumbnail PNG images in a Mysql
>>>> > table.
>>>
>>>> As far as the subject goes, i would say:
>>>> DO NOT TOUCH binary data.....
>>>> Simply store it, or not, in your database.....
>>>
>>> Is it trying to store binary data as character data, or does it think it
>>> needs to string escape binary data types?
>>
>> Escaping strings is a concept only useful when building request strings
>> that include user supplied data. It does avoid concatenating strings
>> whith special/control characters that may interfere with the original
>> language. There is no need to escape strings if you do not embed
>> them inside your request string (eg. if you use bound parameters).
>>
>
> Incorrect. ALL strings, whether user-supplied or not, need to be
> escaped if you don't use bound values.
Well, mostly depends on what is meant by "user-supplied". I realize I
was not explicit enough, so: escaping strings is useful when crafting
interpreted code based on values that are not built in the local
scope, ie. parameters to your crafting process (which I mentionned and
will keep mentionning as user-supplied data, wether it is obtained from
a human operator, a file or basically any routine that is external to
the crafting scope).
>> This is true when dealing with SQL (write prepared statements without
>> including any user supplied data, then bind the parameters), bash
>> commands that only require one exec (use exec* instead of system), and
>> pretty much in any case you construct interpreted code at runtime.
>>
>
> Additional overhead, as I indicated before. Additionally, binding
> numeric values greatly increases the overhead (because they do not
> need to be escaped when not using bound variables). They just need to
> be validated as the appropriate numeric values (which needs to be done
> in either case).
>
There is, indeed, overhead due to the two-step model (preparation, then
execution). However, on a theorical basis, except that operational
overhead, preparing statements mostly have advantages :
* only the symbolic statement is sent as text, data can be shipped in a
proper binary form (which i believe MySQL does as part of a separate
query protocol),
* as a consequence, no need to build and encode strings on the client
side,
* no need to decode those strings on the server side, the server lexer
may process smaller strings,
* no need to escape text data at any time,
* data-independant statement optimizations may be cached.
Even if prepared statements sound theorically ideal, they still *do*
have a couple of conceptual drawbacks:
* replicating queries on multiple servers is much more complex (which
i believe mysql works around by building fully formatted queries sent to
binary logs),
* logging queries suffers the same complexity (requires that data is
encoded and a full text or binary query built on the server side),
* obviously many other related issues.
I am not really into benchmarks and I did not write applications big
enough based on recent MySQL versions to provide some actual feedback, I
suspect however that MySQL imlementation of prepared statements is still
sketchy (especially on the logging, replication and caching sides,
apparently). Maybe performance will improve with future versions of the
statement engine.
I would really like to read some real-world performance feedback on the
matter, if you have some interesting links to share :)
> A little knowledge is a dangerous thing.
I do not feel in a trolling mood, please stop these.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]