> 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
