Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:13538 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 94106 invoked by uid 1010); 26 Oct 2004 21:36:15 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 94063 invoked from network); 26 Oct 2004 21:36:15 -0000 Received: from unknown (HELO ctindustries.net) (216.117.147.250) by pb1.pair.com with SMTP; 26 Oct 2004 21:36:15 -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 i9QKWOs3013723; Tue, 26 Oct 2004 16:32:26 -0400 Message-ID: <087801c4bba4$53904150$f7dea8c0@cyberware.local> To: "Wez Furlong" Cc: References: <064a01c4bb82$8f9d4d90$f7dea8c0@cyberware.local> <417E929B.2040301@cschneid.com> <078e01c4bb96$86a0f340$f7dea8c0@cyberware.local> <4e89b4260410261323dc4d6da@mail.gmail.com> Date: Tue, 26 Oct 2004 17:39:51 -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") I ended up on this tangent only because file:/// support is needed (and from the looks of things is the prefered method for local files over using file://) and how I got stuck in the remote host issue. The following are some syntaxes which are used in windows (tested these with a few browsers and html editors): file://///remotehost/sharename/file.txt file:///D|/file.txt - D being the drive letter file:///D:/file.txt file://D:/file.txt file://D|/file.txt note that file:///\\remotehost\share\file.txt did work under IE and firefox Now, the only reason I am bringing this up as if I were to add the proposed change, anything (as long as prefixed with file:///) would pass that remote host check on windows - how it was before. What is currently there (the change from 8/31) looks way to strict imho as it only allows the format file://D: and nothing else. So it boils down to if there needs to be remote host checking there what is the best way to do it given some of the URIs I mentioned above (otherwise it might as well not be tested under windows since my change to allow file:/// would allow all paths and invalid paths would get caught when the stream was actually tried to be accessed). Rob From: Wez Furlong > The problem with file:// is that the spec deliberately does not define > exactly how file://remotehost/.... works. > > Should file://\\\\remotehost\\share should work ? I guess it is > roughly equivalent to file:///fully/qualified/path, in which case it > should work. > > --Wez.