Description: ------------ i have an application here that stores URLs (among others) in blobs. and it didn't work when I ported it over to MDB2. from what i've seen in MDB2 source code, when inserting a blob and the value turns out to be a URL, MDB2 will replace the value with a handle to the URL and the driver will fetch the URL and put its contents into the blob field instead of the URL itself literally. i see this as a very dangerous design decision and could lead to a lot of potential security hole in end user code. a programmer using MDB2 could easily make a textarea as an input to a blob field. but if he was unaware of the situation (and LOB handling is currently not very well documented), a visitor could input a URL and the application will fetch the URL instead of storing the literal URL itself. and the URL here could be something not normally accessible to the public (when the web server is on DMZ, it could have access to a resource behind the firewall). or worse, it looks like it also accepts file:/ URLs. he could input something like file:///etc/passwd or file:///etc/my.cnf and the server will happily get it for him. if i need to have the ability to store anything including literal URLs in blobs safely, the only way I can see is to turn the string into a stream. and this is not an easy task, especially when considering if someone really needs to fetch an URL into a blob, a handle to it is only one fopen() away, and MDB2 will happily accept a handle as an input for a blob. so, I don't think this 'feature' is well warranted. i think it is better if it is removed, or at least turned off by default.

I see your point. MDB2 does not really make validation of input obsolete. However I fear a lot of people do rely on MDB2 for validation ... or rather on using MDB2 to sanitize their input via quoting or prepare. So maybe MDB2 needs an option to be able to disable this behavior. Of course we also need to documentation :-/

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.