Hi, 2012/4/10 Luke Scott <l...@cywh.com>: > On Apr 9, 2012, at 7:50 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > >> Please don't repeat mistakes for allow_url_include or allow_url_include. >> If admin would like to enforce programmer not to change php.ini. >> They should use Apache httpd and admin_flag/admin_value. >> >> Programmers should have as much control as possible to be >> creative. Optional embedded mode is one of them. There are >> too many thing that programmers should worry. If it can be turned >> off, they are free from it. > > I'm not sure we're talking about the same thing. I'm really confused > about the objections. > > The ini options you mention are not mistakes. You should never be > using include/require for anything other than including local PHP > files. These constructs should have never supported remote files. That
There is valid usage for allow_url_include=on. For instance, if both server and client is PHP, we could use var_export() to receive messages. Client ---- <?php include('http://server/send_my_data.php'); ?> ---- Server: /send_my_data.php ---- <?php echo "$response = "; var_export($some_useful_data); ?> ---- This is the most efficient way to exchange data between PHP servers. People does this should not security issues, though. BTW, do you remember allow_rul_fopen was changed to INI_SYSTEM? This should be INI_ALL as well as allow_rul_include, IMO. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net > was the mistake. The same goes for functions like file_get_contents - > there are more appropriate ways of getting remote content. > file_get_contents isn't nearly as bad though. > > ... But any of the above has nothing to do with this RFC. > > Luke -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php