It possible to add this patch or something along these lines so that
file:/// syntax can be used under windows again?
A change on 8/31 was made to allow for file:// but now prevents file:///
(which is valid)
Index: streams.c
RCS file: /repository/php-src/main/streams/streams.c,v
retrieving revision 1.68
diff -r1.68 streams.c
1496c1496
< if (protocol && path[n+1] == '/' && path[n+2] == '/' && path[n+4] !=
':') {
if (protocol && path[n+1] == '/' && path[n+2] == '/' && path[n+4] != ':'
&& path[n+3] != '/') {
Rob
If you're sure it doesn't break something else, go ahead :)
--Wez
On Tue, 26 Oct 2004 13:38:04 -0400, Rob Richards
rrichards@ctindustries.net wrote:
It possible to add this patch or something along these lines so that
file:/// syntax can be used under windows again?
A change on 8/31 was made to allow for file:// but now prevents file:///
(which is valid)Index: streams.c
RCS file: /repository/php-src/main/streams/streams.c,v
retrieving revision 1.68
diff -r1.68 streams.c
1496c1496
< if (protocol && path[n+1] == '/' && path[n+2] == '/' && path[n+4] !=
':') {if (protocol && path[n+1] == '/' && path[n+2] == '/' && path[n+4] != ':'
&& path[n+3] != '/') {Rob
Rob Richards wrote:
Index: streams.c
RCS file: /repository/php-src/main/streams/streams.c,v
retrieving revision 1.68
diff -r1.68 streams.c
1496c1496
< if (protocol && path[n+1] == '/' && path[n+2] == '/' && path[n+4] !=
':') {if (protocol && path[n+1] == '/' && path[n+2] == '/' && path[n+4] != ':'
&& path[n+3] != '/') {
I'm not an export on that piece of code but passing file:// to this
function could cause problems.
You should at least move the path[n+3] != '/' to before the n+4 test and
I think you should also make sure that n+3 is not '\0' as otherwise n+4
could be beyond the end of the string, no?
Just my $.2,
- Chris
After playing around with it some more, is this that check even needed for
windows to check for remote host access?
What is the different then between doing?:
file_get_contents("\\remotehost\share\file.txt");
file_get_contents("file://\\remotehost\share\file.txt");
With the current streams code, the first one loads fine, while the 2nd one
fails with a "remote host file access not supported" error.
By removing the check, the second one loads fine as well.
Is there some other reason the remote host access check is done when called
using file:// syntax (under windows that is)?
Rob
From: Christian Schneider
I'm not an export on that piece of code but passing file:// to this
function could cause problems.
You should at least move the path[n+3] != '/' to before the n+4 test and
I think you should also make sure that n+3 is not '\0' as otherwise n+4
could be beyond the end of the string, no?
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.
On Tue, 26 Oct 2004 16:01:04 -0400, Rob Richards
rrichards@ctindustries.net wrote:
After playing around with it some more, is this that check even needed for
windows to check for remote host access?
What is the different then between doing?:file_get_contents("\\remotehost\share\file.txt");
file_get_contents("file://\\remotehost\share\file.txt");
With the current streams code, the first one loads fine, while the 2nd one
fails with a "remote host file access not supported" error.
By removing the check, the second one loads fine as well.Is there some other reason the remote host access check is done when called
using file:// syntax (under windows that is)?Rob
From: Christian Schneider
I'm not an export on that piece of code but passing file:// to this
function could cause problems.
You should at least move the path[n+3] != '/' to before the n+4 test and
I think you should also make sure that n+3 is not '\0' as otherwise n+4
could be beyond the end of the string, no?
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.
you could follow the nautilus standard for this and use
smb://hostname/sharename/file.txt ?
Regards
Alan
Rob Richards wrote:
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.txtnote 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.
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
you could follow the nautilus standard for this and use
smb://hostname/sharename/file.txt ?
smb:// should probably be reserved for an actual smb protocol wrapper (one
which works under unix or windows) rather than something which does filepath
magic under one particular OS.
That said libsmb is GPL so any implementation would have to start from
scratch or live outside of php.net
-Sara
That said libsmb is GPL so any implementation would have to start from
scratch or live outside of php.net
AFAIK FreeBSD's libsmb is released under a BSD-style license.
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/smbfs/lib/smb/
Moriyoshi
Moriyoshi Koizumi moriyoshi@at.wakwak.com writes:
AFAIK FreeBSD's libsmb is released under a BSD-style license.
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/smbfs/lib/smb/
That's not libsmb; rather, it's the kernel module that can read/write remote
SMB file systems. libsmb, more properly known as libsmbclient, is a library
which an application may link with for remote access to SMB file systems. It
is part of the Samba project, and is GPL. libsmbclient supports the smb://
URI syntax.
Moriyoshi Koizumi moriyoshi@at.wakwak.com writes:
AFAIK FreeBSD's libsmb is released under a BSD-style license.
http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/smbfs/lib/smb/
That's not libsmb; rather, it's the kernel module that can read/write
remote
SMB file systems. libsmb, more properly known as libsmbclient, is a
library
which an application may link with for remote access to SMB file
systems. It
is part of the Samba project, and is GPL. libsmbclient supports the
smb://
URI syntax.
You are right. But the non-GPL'ed "libsmb" is not exactly a kernel
module but
a set of pieces of code mostly utilised in the filesystem module "smbfs"
out there.
Moriyoshi
If anyone has a chance can you look at this patch (want to make sure its not
breaking anything on other platforms)?
http://ctindustries.net/patches/streams.c.diff
It adds support for file://localhost/ on all platforms as well as adding the
file:/// support back under windows.
Other than that it doesnt change how the remote host stuff is handled.
I'm would like to commit this in about a week and a half when I get back so
please let me know if any one sees any issues.
Rob
It adds support for file://localhost/ on all platforms as well as
adding the
file:/// support back under windows.
Other than that it doesnt change how the remote host stuff is handled.
Couldn't file://127.0.0.1/... or file://[::1]/... be valid URL's
for the local resources?
Moriyoshi
From: Moriyoshi Koizumi
Couldn't file://127.0.0.1/... or file://[::1]/... be valid URL's
for the local resources?
To play it safe I would say no right now. The file uri stuff is being
worked on again:
http://www.ietf.org/internet-drafts/draft-hoffman-file-uri-01.txt
It looks like it is safe to use the following (just implementing empty host
and "localhost" in the streams case for now) as a guideline as other
possible host definitions are being discussed but they all at least include
the following:
where <host> is the fully qualified domain name of the system on
which the <path> is accessible, and <path> is a hierarchical
directory path of the form <directory>/<directory>/.../<name>.
As a special case, <host> can be the string "localhost" or the empty
string; this is interpreted as "the machine from which the URL is
being interpreted".Rob
From: Moriyoshi Koizumi
Couldn't file://127.0.0.1/... or file://[::1]/... be valid URL's
for the local resources?To play it safe I would say no right now. The file uri stuff is being
worked on again:
http://www.ietf.org/internet-drafts/draft-hoffman-file-uri-01.txtIt looks like it is safe to use the following (just implementing empty
host
and "localhost" in the streams case for now) as a guideline as other
possible host definitions are being discussed but they all at least
include
the following:
where <host> is the fully qualified domain name of the system on
which the <path> is accessible, and <path> is a hierarchical
directory path of the form <directory>/<directory>/.../<name>.As a special case, <host> can be the string "localhost" or the empty
string; this is interpreted as "the machine from which the URL is
being interpreted".Rob
Convinced enough. I've never been told that "localhost" is such a
magic spell :) Thanks for the clarification.
Moriyoshi