Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15891
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
	b=q5iRxgGEbV6ILDQmyYPAT7ZobC7pvPKtJVjmWBHa2A6brZ3D0pQU2yOh/fT5ZxYdSP4lq9lIRb1WtMFZFXeUHJNwQp86JEgZJ4cu1aaXPFBmYZKuwMV95qwIDYs4hnYT0d//S7nWDhigf288b8CDNtGJMxtnbQgs0Zh5ENISXN4=
Message-ID: <4e89b4260504070603358c31c5@mail.gmail.com>
Date: Thu, 7 Apr 2005 09:03:37 -0400
Reply-To: Wez Furlong <kingwez@gmail.com>
To: "Morgan L. Owens" <packrat@nznet.gen.nz>
Cc: Sara Golemon <pollita@php.net>, internals@lists.php.net
In-Reply-To: <4254A37D.8070408@nznet.gen.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
References: <425369FD.1000800@nznet.gen.nz>
	<4e89b4260504060541544ccde2@mail.gmail.com>
	<003801c53ab9$a7902650$6c051fac@lighthammer>
	<4e89b426050406083078b02033@mail.gmail.com>
	<001101c53acf$8aa975d0$5c8be5a9@ohr.berkeley.edu>
	<4254A37D.8070408@nznet.gen.nz>
Subject: Re: [PHP-DEV] Scheme identification in stream wrappers: (Partial) disambiguation?
From: kingwez@gmail.com (Wez Furlong)

> If there's something that looks like a scheme (i.e., a well-formed
> sequence of
> characters followed by ':'),
>         see if it's registered;
>         if it is,
>                 the appropriate wrapper should be used.
>         Otherwise,
>                 on platforms where ':' has significance,
>                         try it again as a file path.
> Otherwise, it fails due to an absent stream wrapper.

This is flawed, as we'd then need to introduct sanity checks to
prevent registering a handler over the top of an existing drive on
windows.  Similarly, we'd then be touching the filesystem before
deciding if we should touch the filesystem, which is just wrong (and
slow).
 
> This limits problems to users who are trying to access a child directory
> of the
> current path which happens to have the same name as a registered scheme. The
> problems will consist of the stream failing because the URL it's
> receiving is
> bogus. People in such a situation can use the file: scheme explicitly to
> disambiguate (assuming they can't have a directory whose name starts with
> a double slash!).

Keep in mind that windows tends to treat / as \, and that \\ is
certainly a valid prefix for accessing remote servers over SMB and
also acts as the prefix for such things as windows block device
access.
 
> Alternately,
> on problem platforms,
>         if the string is ambiguous,
>                 see if it is well-formed as a file path.
>                 If it is,
>                         try it as such.
>                 If it's not, or it fails,
>                         see if it starts with a registered scheme name and if so,
>                                 try that.
> It would be easier to check if a string is a well-formed file path than
> it is to
> check if it's a valid URL according to some arbitrary scheme (impossible in
> general).

Really?
Can you guarantee that your user-space code to sniff out the path is
going to work 100% of the time on all platforms?
 
> Assuming no-one tries to register a one-letter scheme, the Windows build
> can get
> away with seeing if the "scheme" is only one letter long, and if it is,
> assume
> that it's a drive letter.

It's not just 1 letter.  There are 3 letter special device names too.

>       DISK$USER:[MY.NOTES]NOTE123456.TXT
> on vms.host.edu to the URL
>         file://vms.host.edu/disk$user/my/notes/note12345.txt
> and noting that to refer to the local machine the host part can be either
> 'localhost' or the empty string.

The file:// protocol is a load of rubbish, because it neglects to
specify how remote file access should work.

What do we really gain from this added complexity?
All I forsee is a bunch of butt-ugly consistency checks all over the
place, to handle platforms and cases where : has significance to the
filesystem.  Not only that, but it will take a lot of trial and error
to make sure things are working properly.

Is there a clear win for PHP, that outweighs the strong risk of
breaking PHP until all the edge cases have been resolved?

--Wez.