Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36117
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 13 Mar 2008 12:55:43 +0200
Message-ID: <06B0D32C7A96544490D18AF653D6BDE5026BA103@il-ex1.zend.net>
Thread-Topic: [PATCH] adding stream wrappers to include_path
Thread-Index: AciAEQF6GSgTXAObT+Ob2BmwBEqZGAE5unPw
To: "Gregory Beaver" <greg@chiaraquartet.net>,
	"internals Mailing List" <internals@lists.php.net>
Subject: RE: [PATCH] adding stream wrappers to include_path
From: dmitry@zend.com ("Dmitry Stogov")

Hi Greg,

In general include_path cannot contain pathes with ':' character,
because it is the POSIX path separator.
So I don't see a way to use stream wrappers in include_path. :(

Thanks. Dmitry.

> -----Original Message-----
> From: Gregory Beaver [mailto:greg@chiaraquartet.net]=20
> Sent: Friday, March 07, 2008 8:06 AM
> To: Dmitry Stogov; internals Mailing List
> Subject: [PATCH] adding stream wrappers to include_path
>=20
>=20
> Hi,
>=20
> I found some time to whip up a quick patch against 5.3.
>=20
> This patch allows adding stream wrappers to include_path on=20
> both windows and unix.  This means one can set an=20
> include_path to=20
> ".:/usr/local/lib/php:phar:///path/to/ZF.phar/lib" or the=20
> windows equivalent ".;C:\php5;phar://C:/php5/ZF.phar/lib" =20
> Any stream wrapper, userspace or built-in, will work as long=20
> as it satisfies security constraints and implements=20
> url_stat(), stream_open(), stat(), and read() or the C equivalents.
>=20
> In other words, this test I already had created for pecl/phar works:
>=20
> <?php
> $fname =3D dirname(__FILE__) . '/tempmanifest1.phar.php';
> $a =3D new Phar($fname);
> $a['file1.php'] =3D 'file1.php
> ';
> $a['test/file1.php'] =3D 'test/file1.php
> ';
> unset($a);
> set_include_path('.' . PATH_SEPARATOR . 'phar://' . $fname);=20
> include 'file1.php'; set_include_path('.' . PATH_SEPARATOR .=20
> 'phar://' . $fname . '/test'); include 'file1.php'; include=20
> 'file2.php'; ?> =3D=3D=3DDONE=3D=3D=3D
>=20
> with output:
>=20
> --EXPECTF--
> file1.php
> test/file1.php
>=20
> Warning: include(file2.php): failed to open stream: No such=20
> file or directory in %sinclude_path.php on line %d
>=20
> Warning: include(): Failed opening 'file2.php' for inclusion
> (include_path=3D'.:phar:///home/cellog/workspace/php5/ext/phar/t
> ests/tempmanifest1.phar.php/test')
> in %sinclude_path.php on line %d
> =3D=3D=3DDONE=3D=3D=3D
>=20
> The internals of the patch borrows logic from=20
> php_stream_locate_url_wrapper to quickly detect a stream=20
> wrapper.  It excludes the data stream wrapper out of hand as=20
> this has no business in include_path for obvious reasons.  It=20
> also fully supports disabled=20
> allow_url_fopen/allow_url_include by passing=20
> STREAM_OPEN_FOR_INCLUDE to the eventual=20
> php_stream_locate_url_wrapper call.  The most important part=20
> of the patch is the way it finds a stream wrapper on unix. =20
> Because PATH_SEPARATOR is ":" on unix, the include_path=20
> scanner will stop after "phar" in the sample include_paths=20
> above.  The new scanner checks for a valid stream wrapper (a=20
> sequence of alpha-numeric, +, -, or . characters followed by=20
> ://) and seeks to the next : if found.
>=20
> My primary concern with the patch is performance.  I'm=20
> certain it can be tweaked.  I extracted the call to url_stat=20
> from php_stream_stat(), which removes the possibility of=20
> hitting stat cache but eliminates the redundant call to=20
> php_stream_locate_url_wrapper.  If it is indeed faster to use=20
> php_stream_stat(), that's one easy optimization.
>=20
> In any case, it adds an additional scan of each include_path=20
> component to detect stream wrappers, which is called on each=20
> include.  This may be the biggest candidate for optimization,=20
> as a simple cache of paths with stream wrapper/not could be=20
> created whenever include_path is set and used instead of=20
> scanning the string every time.
>=20
> By the way, there may be some unsafe scans in=20
> php_stream_locate_url_wrapper, specifically line 1531 in PHP_5_3:
>=20
>     if ((*p =3D=3D ':') && (n > 1) && (!strncmp("//", p+1, 2) ||=20
> !memcmp("data", path, 4))) {
>=20
> It doesn't seem to verify that path is at least 4 or there is=20
> at least 2 extra characters after p before checking for "//" or "data"
>=20
> Thanks,
> Greg
>=20