PHP SELF not returning URL

and nor are any PHP server variables. PHP or Apache issue?

[penders]

My problem seems to be closely related to the issue raised in this thread: [webmasterworld.com...]
but that was a few months ago and a satisfactory solution did not seem to be found.

I use $_SERVER["SCRIPT_NAME"] in order to work out where on the server the PHP app has been installed. This is then used (amongst other things) to build absolute links in the resulting page sent to the client, of the form:

<a href="<?=_INSTALLDIR?>index.php">Link</a>

This works great on a couple of development servers, with a fairly standard Apache installation, but on the big ol' live server (Apache 2, PHP 5) it doesn't. This seems to be because of either virtual directories and/or URL rewriting (?!) that results in SCRIPT_NAME / PHP_SELF etc. all returning the file system path to the current file, and *NOT* the URL that appears in the address bar, which is required to build the links.

The PHP app seems to be installed here:

/actualdir/index.php

which is what SCRIPT_NAME, SCRIPT_FILENAME, PHP_SELF, REQUEST_URI all return.

However, the URL that the browser/client sees is:

/virtdir1/virtdir2/index.php

and unfortunately I cannot find any PHP variables which return this path information.

The problem is that if you try to follow a link to (or type into the address bar) "

/actualdir/index.php

" you get a 404 error. So, the 'virtual' address is reqd. I would have thought, however, that the server should be configured to allow any requests to "

/actualdir/index.php

" and 'redirect' or handle them appropriately, but it doesn't. Unfortunately I don't know how the live server is configured, nor have any direct control over it! (Besides, I'm not an Apache guru)

Is it an issue in my PHP code that I can resolve, or is it a server admin issue?!

The problem is also in my forms, where I set the action:

<form action="<?=$_SERVER["PHP_SELF"]?>"...

A fairly standard method I would have thought, but this results in a 404 error. I can, however, easily resolve this issue by simply hard coding the action(!)

I can also resolve the

_INSTALLDIR

issue by again hard coding this as a constant in my config file, but this is undesirable, and I would hope unnecessary (certainly the client doesn't like it, whom incidentally is supposed to have Apache-guru like abilities), with foreseeable complications in the future for this and other projects.

Any comments appreciated, thanks.

[Birdman]

Is there a file called .htaccess in the root directory or /actualdir/ directory?

[penders]

Unfortunately I don't know! I see no reason why we couldn't have one if reqd, but unfortunately I don't have direct access to the live server (this I realise is a problem in itself, trying to solve what could potentially be a server issue?!).

What are you thinking? Issueing a redirect or something? But redirecting to a virtual location?

Incidentally, the 'Apache-guru like' guy on the live server seems to think it is a downfall of PHP and not the Apache setup that is the problem. Only I'm not convinced.

[Little_G]

Hi,

Have you tryed var_dump [php.net]ing the $_SERVER array, sometimes I get things like REDIRECT_SCRIPT_URL come up, dumping it will let you see them all.

Andrew

[penders]

I have not explicitly

var_dump

'ed the $_SERVER array, although I have examined the output from

phpinfo()

which I believe should contain the same information - can

phpinfo()

miss anything?

From

phpinfo()

, nothing relates to the virtual path / the URL in the address bar.

[Little_G]

Hi,

Did you use a seperate phpinfo.php file, if so then it might not be affected by the same problem.

Andrew

[penders]

Yes, I used a separate

phpinfo.php

file, but it was in the same directory / location as the affected file(s), so I cannot imagine that it would produce any different results?!

[penders]

Hhhhmmmm, from the response, am I to assume that this is an (Apache) SERVER configuration issue, as opposed to a purely programmatic PHP issue?

In that, either...

- PHP *should* be returning, as one of the $_SERVER or $_ENV superglobals, a value that includes the client-side URL of the current page ...?

Or,

- The server *should* at least handle any requests to

/actualdir/index.php

and 'redirect' them appropriately ...?

[coopster]

The $_SERVER [php.net] superglobal array contains variables set by the web server or otherwise directly related to the execution environment of the current script. The entries in this array are created by the web server. There is no guarantee that every web server will provide any of these.

Yes, PHP is tightly integrated with the Apache server and you'll need to know specifics about setup for certain variables if you intend to use them effectively.

phpinfo() [php.net] will tell you a lot of information but sometimes it is just easier to dump that $_SERVER superglobal to have a quick peek. You can do this as simple as

<pre> 
<?php phpinfo();?> 
</pre>

or better yet, have a look at the the "superglobals" snippet in this past thread:Good PHP solutions to small problems [webmasterworld.com]

[penders]

Thanks for the info coopster... I've been having a good read of that last link and related threads - will need to come back to that one later.

My problem, however, is that PHP is not returning anything that relates to the path in the current URL in the address bar - on this particular server - it may have been rewritten / a virtual directory or something? But, from the client end, the server can only handle requests to this URL path. Which makes it impossible for me to build (using PHP), absolute links in the resulting HTML pages.

- The workaround so far has been to simply hard-code this path as a constant in the configuration file, which works ok-ish for the moment, but if someone wants to move the app later this may need to be altered. And one of the goals initially was to make this completely independent of the folder structure.

- I've thought about changing all the links to relative paths. A lot of hassle and I'm not even sure it would work thoughout?!

- Also thought about the possibility of using JavaScript (on the very first page request) to send back to the server the actual URL, save it and then use this saved response for subsequent requests...? But this seems like a bit too much hassle for what should really be a simple problem?! And besides, the appropriate permissions probably won't be set, and it's not a DB app.

Hhhhmmm, anyway, thanks for your responses. Like I say 'an easy' workaround exists, but a none hard-coded solution would be better. Only I can't help but feel that this could be resolved with a bit of server-configuration, unfortunately that is out of my control in this case.

[coopster]

unfortunately that is out of my control in this case.

And that is exactly where I would start, too. Ask the hosting provider your questions. I'm interested to see what you find out.

[penders]

I'm interested to see what you find out.

Me too! :)