Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:13561 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36528 invoked by uid 1010); 27 Oct 2004 11:28:35 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 36502 invoked from network); 27 Oct 2004 11:28:35 -0000 Received: from unknown (HELO ctindustries.net) (216.117.147.250) by pb1.pair.com with SMTP; 27 Oct 2004 11:28:35 -0000 Received: from ctdprimary (dsta-aa203.pivot.net [66.186.171.203]) (authenticated bits=0) by ctindustries.net (8.12.8/8.12.8) with ESMTP id i9RAJ9s3016740; Wed, 27 Oct 2004 06:19:12 -0400 Message-ID: <026001c4bc17$d3ad5bc0$f7dea8c0@cyberware.local> To: "Alan Knowles" Cc: "Wez Furlong" , References: <064a01c4bb82$8f9d4d90$f7dea8c0@cyberware.local> <417E929B.2040301@cschneid.com> <078e01c4bb96$86a0f340$f7dea8c0@cyberware.local> <4e89b4260410261323dc4d6da@mail.gmail.com> <087801c4bba4$53904150$f7dea8c0@cyberware.local> <417EE61A.2080708@akbkhome.com> Date: Wed, 27 Oct 2004 07:26:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: Re: [PHP-DEV] Re: streams file uri under windows From: rrichards@ctindustries.net ("Rob Richards") From: Alan Knowles > you could follow the nautilus standard for this and use > smb://hostname/sharename/file.txt ? Can't do that as this is stemming from an issue with libxml. It uses the file:/// syntax when needed. Currently with the change in streams, it fails the check as it is now deemed to be a remote host. This causes the libxml I/O handler to fall back to its internal file handling which I would eventually like to diasable all libxml I/O and not allow it to fallback on anything if it cant match a php stream handler. That being said, imo either the check should be tightened up a bit (for all platforms) or just removed and let it issue whatever error it currently does if it cant open the stream. using file://localhost/localpath will fail on all platforms - though it perfectly legal. file:/// will fail just on windows due to the current check, but on other platforms will allow anything after it. If I make that proposed change, it will allow file:/// but since you can place any path after that (local or remote) and it works, it makes the check a little pointless. I have no problem adding my change in there, but it seems that it just adds to the wtf factor since if you then use the file:/// syntax, you are free to use any path you want to bypass the remote host check. Rob