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