Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29527
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 66.79.163.178 cause and error)
Message-ID: <464E1AA8.9050600@php.net>
Date: Fri, 18 May 2007 16:29:12 -0500
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: php-dev <internals@lists.php.net>
References: <464DCB8C.90803@chiaraquartet.net> <464DEF23.3080503@zend.com> <464DF139.6090405@zend.com>
In-Reply-To: <464DF139.6090405@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
From: cellog@php.net (Greg Beaver)

Stanislav Malyshev wrote:
> 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.

This is cleaner than my suggestion, I like it.  It would also be very
easy to implement.

Greg