Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29525
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender)
Message-ID: <464DF139.6090405@zend.com>
Date: Fri, 18 May 2007 11:32:25 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: php-dev <internals@lists.php.net>
References: <464DCB8C.90803@chiaraquartet.net> <464DEF23.3080503@zend.com>
In-Reply-To: <464DEF23.3080503@zend.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
From: stas@zend.com (Stanislav Malyshev)

oh, and I forgot another thing:

5. Have some function like stream_is_remote() which could check URL for 
remote-ness,
so that the responsible stream wrapped would not rely on fopen erroring out.
I couldn't locate such function, so if it isn't there it should be added.

> I think the problem could be solved this way:
> 0. allow_url_include and allow_url_fopen renamed to allow_remote_include 
> and allow_remote_fopen (not really necessary, just much cleaner, if you 
> don't like it, ignore it for now).
> 1. By default, allow_remote_inclue=0, allow_remote_fopen=1
> 2. Stream can be of three types - remote, local and user/local.
> 3. User streams can be declared when registered as either remote or 
> user/local, remote being the default.
> 4. When operation on user/local stream is run, allow_remote_fopen is 
> disabled if allow_remote_include was disabled.

-- 
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/