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
