Everything

php

streams file uri under windows

php.internals

Rob Richards

21 years ago

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

Wez Furlong

21 years ago

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:

Christian Schneider

21 years ago

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

Rob Richards

21 years ago

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

Wez Furlong

21 years ago

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:

Rob Richards

21 years ago

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

Alan Knowles

21 years ago

you could follow the nautilus standard for this and use
smb://hostname/sharename/file.txt ?

Regards
Alan

Rob Richards wrote:

Rob Richards

21 years ago

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

Sara Golemon

21 years ago

> 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

Moriyoshi Koizumi

21 years ago

On 2004/10/28, at 0:55, Sara Golemon wrote:

> 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

Unnamed Person

21 years ago

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

21 years ago

On 2004/10/28, at 2:24, Derrell.Lipman@UnwiredUniverse.com wrote:

> 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

Rob Richards

21 years ago

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

Moriyoshi Koizumi

21 years ago

On 2004/10/27, at 23:28, Rob Richards wrote:

> 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

Rob Richards

21 years ago

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

Moriyoshi Koizumi

21 years ago

On 2004/10/28, at 3:28, Rob Richards wrote:

> 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

Convinced enough. I've never been told that "localhost" is such a
magic spell :) Thanks for the clarification.

Moriyoshi