SSI & PHP Question

[FredAt]

Calling a PHP script via an SSI virtual directive is plain sailing. However, the script when run does not provide anything useful for $_SERVER['HTTP_REFERER']. What I need is to determine the SHTML page from which the script was called. SSI allows me to set a variable to contain the page URL but it is not clear to me that I can somehow pass this variable as a parameter in the script call. If there is some way of accomplishing what I am after I would love to know.

[coopster]

Dump the $_SERVER superglobal array to your browser. You may find what you seek in there ...

print '<pre>'; 
print_r($_SERVER); 
print </pre>'; 
exit;

[FredAt]

Thanks for the print_r tip - always useful to know. I suppose there are minor variations in just what $_SERVER contains depending on the Apache implementation. In any case, I found that it does not have anything that would be useful for my needs.

Conclusion - calling a PHP script via an SSI directive and expecting to have access to the SHTML page from which it was called in PHP is not feasible.

I have found a work around - call the script from the browser after the page has been loaded. This works, but at a price - one extra round trip to the server.

[FredAt]

I subsequently tried dumping the $GLOBALS superglobal. While it still does not provide anything useful in the PHP from SSI context I found that it lists three additional variables - $GLOBALS['x'], $GLOBALS['i'] and $GLOBALS['p']. I cannot find any description of these variables in the PHP documentation. Any ideas?

[jdMorgan]

I'm a crusty old PERL guy, but when I need to do something like this, I just append a query string to the "include" URL-path that includes the REQUEST_URI of the calling page, and then the script sees that as a GET variable.

<!--#include virtual="/cgi-local/print_schedule.pl?called_from=${REQUEST_URI}" -->

That should also work with PHP, I believe.

Jim

[FredAt]

REQUEST_URI works just fine. The important bit is wrapping it in {} or else all fails. I was trying HTTP_REFERER which failed - logically I suppose since the script had not been launched by an HTTP request

[coopster]

Conclusion - calling a PHP script via an SSI directive and expecting to have access to the SHTML page from which it was called in PHP is not feasible.

Invalid conclusion ;)

If you dump the PHP superglobal $_SERVER array in the PHP script which is the target of your SSI then you should see the REQUEST_URI index in there and it will contain the exact same thing as the variable being passed in your GET request via the SSI invocation (if the document containing the SSI is the same as that URI being requested).

[FredAt]

Yes, I figured that out when I did a live test on the web server running on my site. My local web server - a Windows freebie with a partial implementation of SSI - is where it failed.