'undefined function' error if I use a fully-qualifed include

[Puzzled]

This is a weird problem, but perhaps someone else has seen it before
(I hope!)

If I use a fully qualified include call

include ( 'http://localhost/subtree/filename.php')

I get an 'undefined function' error when calling a routine that's
defined in that file.

(I know the file is being included and the parser is at least seeing
the definition because I put disclosure echos before and after the
definition, and the echos work.)

But the error goes away and the function executes if I use a relative
reference

include ('subtree/filename.php')

even though subtree is *not* declared in the include_path config var
in php.ini.

Thanks in advance for any ideas. I'm stumped!

-Puzzled in Rainy Massachusetts

[Oli Filth]

Re: 'undefined function' error if I use a fully-qualifed include

Puzzled said the following on 18/10/2005 17:54:[color=blue]
> This is a weird problem, but perhaps someone else has seen it before
> (I hope!)
>
> If I use a fully qualified include call
>
> include ( 'http://localhost/subtree/filename.php')
>
> I get an 'undefined function' error when calling a routine that's
> defined in that file.[/color]

AAARGH! This question comes up practically every week!

This is an absolute *HTTP* URL, not an absolute *filesystem* URL. So it
obtains filename.php by performing an HTTP request to the specified
server, which just happens to be "localhost" in this case.

And of course, a server set up to parse and execute PHP files will parse
and execute filename.php when it's requested, so all your include() call
sees is the output result of filename.php.



--
Oli

[Puzzled]

Re: 'undefined function' error if I use a fully-qualifed include

Oli Filth wrote:
[color=blue]
>Puzzled said the following on 18/10/2005 17:54:[color=green]
>> This is a weird problem, but perhaps someone else has seen it before
>> (I hope!)
>>
>> If I use a fully qualified include call
>>
>> include ( 'http://localhost/subtree/filename.php')
>>
>> I get an 'undefined function' error when calling a routine that's
>> defined in that file.[/color]
>
>AAARGH! This question comes up practically every week!
>
>This is an absolute *HTTP* URL, not an absolute *filesystem* URL. So it
>obtains filename.php by performing an HTTP request to the specified
>server, which just happens to be "localhost" in this case.
>
>And of course, a server set up to parse and execute PHP files will parse
>and execute filename.php when it's requested, so all your include() call
>sees is the output result of filename.php.[/color]

Thanks much for your quick reply.

I think I must be missing something important still, because I don't
understand what you said. Check me on this, would you?

A URL is just another filesystem reference, but using a highly
generalized syntax that's independent of o/s and physical
location--like NFS, but more general. So any processing that would
be done or not done to a file would be independent of the type of
reference used to retrieve it.

When the php interpreter knows it's operating on an include file, it
should know enough not to start a new symbol table, but instead add
things like function definitions to the existing symbol table it
started building when it read up the outermost file.

But that doesn't appear to be what's happening. It looks to me as
though it's treating the .php extension as being more important than
the fact the file is being included, so instead of continuing the same
symbol table, it's building a special one for that file and then
discarding it.

Is that what's causing the problem, the fact that I'm using a .php
extension on the include file?

That would make a crazy sort of sense, since the php interpreter would
do its own filesystem fetches, but might hand any url reference, even
one for an include, off to Apache to satisfy. And somewhere in that
process, the fact that it's just an include file is getting pushed and
the file is being interpreted as though it were a completely new job.
Whereas if it had some .inc or .foo extension, Apache wouldn't try to
pass it through the interpreter, but would just hand it over.

still Puzzled, but struggling
--
(To mail me, please change .not.invalid to .net, first.
Apologies for the inconvenience.)

[Oli Filth]

Re: 'undefined function' error if I use a fully-qualifed include

Puzzled wrote:[color=blue]
> Oli Filth wrote:
>[color=green]
> >Puzzled said the following on 18/10/2005 17:54:[color=darkred]
> >> If I use a fully qualified include call
> >>
> >> include ( 'http://localhost/subtree/filename.php')
> >>
> >> I get an 'undefined function' error when calling a routine that's
> >> defined in that file.[/color]
> >
> >This is an absolute *HTTP* URL, not an absolute *filesystem* URL. So it
> >obtains filename.php by performing an HTTP request to the specified
> >server, which just happens to be "localhost" in this case.
> >
> >And of course, a server set up to parse and execute PHP files will parse
> >and execute filename.php when it's requested, so all your include() call
> >sees is the output result of filename.php.[/color]
>
> I think I must be missing something important still, because I don't
> understand what you said. Check me on this, would you?
>
> A URL is just another filesystem reference, but using a highly
> generalized syntax that's independent of o/s and physical
> location--like NFS, but more general. So any processing that would
> be done or not done to a file would be independent of the type of
> reference used to retrieve it.[/color]

In this case, not really, because the URL is prefixed with "http://",
which specifies "Go and get this resource using the HTTP protocol".

The fact is that you're requesting "filename.p hp" via HTTP. PHP doesn't
know that you're expecting it to implicitly convert
"http://localhost/..." to a local filesystem reference, so it simply
sends out an HTTP request for that file, just as if you'd typed
"http://localhost/.../filename.php" into your browser.

The request just so happens to be to your own server, which serves this
request by processing filename.php spitting the output back as the HTTP
response. This HTTP response is then included into the original PHP
file.
[color=blue]
> When the php interpreter knows it's operating on an include file, it
> should know enough not to start a new symbol table, but instead add
> things like function definitions to the existing symbol table it
> started building when it read up the outermost file.[/color]

This is impossible, because filename.php is processed in a completely
separate instance to the original PHP file, serving an entirely
separate HTTP request.
[color=blue]
> Is that what's causing the problem, the fact that I'm using a .php
> extension on the include file?
>
> That would make a crazy sort of sense, since the php interpreter would
> do its own filesystem fetches, but might hand any url reference, even
> one for an include, off to Apache to satisfy. And somewhere in that
> process, the fact that it's just an include file is getting pushed and
> the file is being interpreted as though it were a completely new job.
> Whereas if it had some .inc or .foo extension, Apache wouldn't try to
> pass it through the interpreter, but would just hand it over.[/color]

Yup, that's the explanation in a nutshell (except that the first PHP
instance doesn't request filename.php directly from Apache, it does it
via an HTTP request which lands at Apache indirectly).

The simplest solution would be to not include() local files via HTTP.

Even if you renamed your include files to .inc extensions, this would
be insecure, since anyone could request them via HTTP and view your
source code.

--
Oli

[juglesh]

Re: 'undefined function' error if I use a fully-qualifed include


Puzzled wrote:[color=blue]
> This is a weird problem, but perhaps someone else has seen it before
> (I hope!)
>
> If I use a fully qualified include call
>
> include ( 'http://localhost/subtree/filename.php')
>
> I get an 'undefined function' error when calling a routine that's
> defined in that file.
>
> (I know the file is being included and the parser is at least seeing
> the definition because I put disclosure echos before and after the
> definition, and the echos work.)
>
> But the error goes away and the function executes if I use a relative
> reference
>
> include ('subtree/filename.php')
>
> even though subtree is *not* declared in the include_path config var
> in php.ini.[/color]

if the subtree folder is in the same folder as the current script, php
knows to look for that folder in the current folder. same as include
'filename.php', it looks in the current folder.

if you are looking to include a file relative to the main folder of
your site, try
include $_SERVER['DOCUMENT_ROOT'].'subtree/filename.php'
(you may need a slash before subtree)

--
juglesh

[Puzzled]

Re: 'undefined function' error if I use a fully-qualifed include

Oli Filth wrote:
[color=blue]
>Puzzled wrote:[color=green]
>> Oli Filth wrote:
>>[color=darkred]
>> >Puzzled said the following on 18/10/2005 17:54:
>> >> If I use a fully qualified include call
>> >>
>> >> include ( 'http://localhost/subtree/filename.php')
>> >>
>> >> I get an 'undefined function' error when calling a routine that's
>> >> defined in that file.
>> >
>> >This is an absolute *HTTP* URL, not an absolute *filesystem* URL. So it
>> >obtains filename.php by performing an HTTP request to the specified
>> >server, which just happens to be "localhost" in this case.
>> >
>> >And of course, a server set up to parse and execute PHP files will parse
>> >and execute filename.php when it's requested, so all your include() call
>> >sees is the output result of filename.php.[/color]
>>
>> I think I must be missing something important still, because I don't
>> understand what you said. Check me on this, would you?
>>
>> A URL is just another filesystem reference, but using a highly
>> generalized syntax that's independent of o/s and physical
>> location--like NFS, but more general. So any processing that would
>> be done or not done to a file would be independent of the type of
>> reference used to retrieve it.[/color]
>
>In this case, not really, because the URL is prefixed with "http://",
>which specifies "Go and get this resource using the HTTP protocol".
>
>The fact is that you're requesting "filename.p hp" via HTTP. PHP doesn't
>know that you're expecting it to implicitly convert
>"http://localhost/..." to a local filesystem reference, so it simply
>sends out an HTTP request for that file, just as if you'd typed
>"http://localhost/.../filename.php" into your browser.
>
>The request just so happens to be to your own server, which serves this
>request by processing filename.php spitting the output back as the HTTP
>response. This HTTP response is then included into the original PHP
>file.
>[color=green]
>> When the php interpreter knows it's operating on an include file, it
>> should know enough not to start a new symbol table, but instead add
>> things like function definitions to the existing symbol table it
>> started building when it read up the outermost file.[/color]
>
>This is impossible, because filename.php is processed in a completely
>separate instance to the original PHP file, serving an entirely
>separate HTTP request.
>[color=green]
>> Is that what's causing the problem, the fact that I'm using a .php
>> extension on the include file?
>>
>> That would make a crazy sort of sense, since the php interpreter would
>> do its own filesystem fetches, but might hand any url reference, even
>> one for an include, off to Apache to satisfy. And somewhere in that
>> process, the fact that it's just an include file is getting pushed and
>> the file is being interpreted as though it were a completely new job.
>> Whereas if it had some .inc or .foo extension, Apache wouldn't try to
>> pass it through the interpreter, but would just hand it over.[/color]
>
>Yup, that's the explanation in a nutshell (except that the first PHP
>instance doesn't request filename.php directly from Apache, it does it
>via an HTTP request which lands at Apache indirectly).
>
>The simplest solution would be to not include() local files via HTTP.
>
>Even if you renamed your include files to .inc extensions, this would
>be insecure, since anyone could request them via HTTP and view your
>source code.[/color]

Again thanks for another prompt response (more prompt than mine, since
everyone's having phone problems around here due to rain)

So it sounds as though there's no really good, general solution.
Either I use an extension that doesn't trigger interpretation, and
suffer code-snooping, or I keep duplicate copies on each server and
load using relative refs. *sigh*

Many thanks for the deconfusion!

- less-Puzzled-now

[Jerry Stuckle]

Re: 'undefined function' error if I use a fully-qualifed include

Puzzled wrote:[color=blue]
> Oli Filth wrote:
>
>[color=green]
>>Puzzled wrote:
>>[color=darkred]
>>>Oli Filth wrote:
>>>
>>>
>>>>Puzzled said the following on 18/10/2005 17:54:
>>>>
>>>>>If I use a fully qualified include call
>>>>>
>>>>> include ( 'http://localhost/subtree/filename.php')
>>>>>
>>>>>I get an 'undefined function' error when calling a routine that's
>>>>>defined in that file.
>>>>
>>>>This is an absolute *HTTP* URL, not an absolute *filesystem* URL. So it
>>>>obtains filename.php by performing an HTTP request to the specified
>>>>server, which just happens to be "localhost" in this case.
>>>>
>>>>And of course, a server set up to parse and execute PHP files will parse
>>>>and execute filename.php when it's requested, so all your include() call
>>>>sees is the output result of filename.php.
>>>
>>>I think I must be missing something important still, because I don't
>>>understand what you said. Check me on this, would you?
>>>
>>>A URL is just another filesystem reference, but using a highly
>>>generalize d syntax that's independent of o/s and physical
>>>location--like NFS, but more general. So any processing that would
>>>be done or not done to a file would be independent of the type of
>>>reference used to retrieve it.[/color]
>>
>>In this case, not really, because the URL is prefixed with "http://",
>>which specifies "Go and get this resource using the HTTP protocol".
>>
>>The fact is that you're requesting "filename.p hp" via HTTP. PHP doesn't
>>know that you're expecting it to implicitly convert
>>"http://localhost/..." to a local filesystem reference, so it simply
>>sends out an HTTP request for that file, just as if you'd typed
>>"http://localhost/.../filename.php" into your browser.
>>
>>The request just so happens to be to your own server, which serves this
>>request by processing filename.php spitting the output back as the HTTP
>>response. This HTTP response is then included into the original PHP
>>file.
>>
>>[color=darkred]
>>>When the php interpreter knows it's operating on an include file, it
>>>should know enough not to start a new symbol table, but instead add
>>>things like function definitions to the existing symbol table it
>>>started building when it read up the outermost file.[/color]
>>
>>This is impossible, because filename.php is processed in a completely
>>separate instance to the original PHP file, serving an entirely
>>separate HTTP request.
>>
>>[color=darkred]
>>>Is that what's causing the problem, the fact that I'm using a .php
>>>extension on the include file?
>>>
>>>That would make a crazy sort of sense, since the php interpreter would
>>>do its own filesystem fetches, but might hand any url reference, even
>>>one for an include, off to Apache to satisfy. And somewhere in that
>>>process, the fact that it's just an include file is getting pushed and
>>>the file is being interpreted as though it were a completely new job.
>>>Whereas if it had some .inc or .foo extension, Apache wouldn't try to
>>>pass it through the interpreter, but would just hand it over.[/color]
>>
>>Yup, that's the explanation in a nutshell (except that the first PHP
>>instance doesn't request filename.php directly from Apache, it does it
>>via an HTTP request which lands at Apache indirectly).
>>
>>The simplest solution would be to not include() local files via HTTP.
>>
>>Even if you renamed your include files to .inc extensions, this would
>>be insecure, since anyone could request them via HTTP and view your
>>source code.[/color]
>
>
> Again thanks for another prompt response (more prompt than mine, since
> everyone's having phone problems around here due to rain)
>
> So it sounds as though there's no really good, general solution.
> Either I use an extension that doesn't trigger interpretation, and
> suffer code-snooping, or I keep duplicate copies on each server and
> load using relative refs. *sigh*
>
> Many thanks for the deconfusion!
>
> - less-Puzzled-now[/color]

PMJI, but I think you're better having duplicate copies of your code on
each server.

For instance - what happens if the server holding the (single) copy of
your code goes down? It does happen! :-) None of the other servers would
be able to access the code - and all would effectively be down.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===