Re: RFC: source files without opening tag
| From: | Yasuo Ohgaki | Date: | Tue, 10 Apr 2012 03:25:23 +0000 |
| Subject: | Re: RFC: source files without opening tag | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-59610@lists.php.net to get a copy of this message | ||
Hi,
2012/4/10 Luke Scott <luke@cywh.com>:
> On Apr 9, 2012, at 7:50 PM, Yasuo Ohgaki <yohgaki@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
yohgaki@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