Php Includes Stopped Working

[esprague]

As of this morning our php includes only work when there is no "http://www.x.com/"'>http://www.x.com/" in the path. We need to get things working again such that we can have "http://www.x.com/" in the path.

 

For example, if there is a file called a.php in the root directory then

include("./a.php"); //still works

include("http://www.x.com/a.php"); //no longer works

 

We have too many php includes to change, instead we need to figure out why the includes with the http and the www in the path no longer work.

 

We've had includes this way for years without any changes. We haven't made any updates or installs recently. We haven't made any coding changes recently. Everything was fine on our site last night.

 

The php.ini file looks ok, what else should we check?

 

Thanks,

Eric

[TCH-Andy]

Hi Eric,

 

When it doesn't work, what error message do you get ? (Check in the error log, within cpanel).

 

Which server are you on? One that has been recently upgraded? Or one with no changes to your knowledge.

 

Have you made any other changes? And is your DNS all set correctly?

[esprague]

Andy,

 

Thanks for pointing out the error log in cpanel. It is easier than doing tail on /usr/local/apache/logs/error_log plus the results can be copied and pasted. With the full path include issues we don't see errors in the log file. On the browser side we are just redirected to the home page.

 

We're on 2 fully managed dedicated servers (but I'm not worried about the db server right now). As for the http server, I don't know if it has been upgraded recently.

 

We haven't made other changes. To my knowledge our DNS has not changed in awhile.

 

We do see some other new errors in error_log from scripts with includes where root_path for the include is defined as follows: define('root_path', ''); (these scripts worked fine last night). Here are these new errors:

>[Fri Oct  6 02:18:49 2006] [error] PHP Warning:  main(): Failed opening 'lang/english.php' for inclusion (include_path='.:/usr/lib/php:/usr/local/lib/php') in /home/eproxim/public_html/reviews/inc/global.php on line 101
[Fri Oct  6 02:18:49 2006] [error] PHP Warning:  main(lang/english.php): failed to open stream: No such file or directory in /home/eproxim/public_html/reviews/inc/global.php on line 101
[Fri Oct  6 02:18:49 2006] [error] PHP Warning:  main(lang/english.php): failed to open stream: No such file or directory in /home/eproxim/public_html/reviews/inc/global.php on line 101

 

Thanks,

Eric

Edited October 6, 2006 by esprague

[TCH-Andy]

Eric,

 

Can you open a ticket, and ask the techs to check the security settings on the server (for the first problem) and also the root_path in the php.ini for the second issue.

[esprague]

Eric,

 

Can you open a ticket, and ask the techs to check the security settings on the server (for the first problem) and also the root_path in the php.ini for the second issue.

I opened a ticket this morning when the scope of the issue was broad. When we identified the issue as specific php includes I closed the old ticket and opened a new one this afternoon. I just added your questions to the ticket.

[esprague]

Andy,

 

I was talking with Vivek on aim last night. He said the dedicated servers are not upgraded without notification.

 

Here is what php.ini has for include_path:

>include_path .:/usr/lib/php:/usr/local/lib/php .:/usr/lib/php:/usr/local/lib/php

and allow_url_open:

>allow_url_fopen On On

 

The ticket is still open. I know it isn't a scripting issue, we've had these scripts in place for years and they haven't changed. Also, I have the same identical scripts on other sites hosted at TotalChoice and they're still working fine. On the server side I'm not sure what configuration settings we should be looking at outside of php.ini

 

The only thing that has changed recently is that our designer made some email forwarding changes in cpanel the night before the includes stopped working but I don't see how email forwarding could possibly be related to this.

[esprague]

Here is the latest, curl was manuall reinstalled by support but our php includes are still not working. Note that the only php script that is still ok is our phpBB forum.

 

--------------------------------------------------------------------------------

SUPPORT

--------------------------------------------------------------------------------

I accidently came across this error message

 

-------------

Untarring curl......Done

./configure [@curl-7.15.3]...(--prefix=/usr)...................................Done

make [@curl-7.15.3]...(-j 1).........................................................Done

make [@curl-7.15.3]...(install)....Done

make[3]: *** [install-binPROGRAMS] Error 1

make[2]: *** [install-am] Error 2

make[1]: *** [install] Error 2

make: *** [install-recursive] Error 1

-------------

 

I have manually reinstalled curl in the server. Could you please check it out once again? It seems like the link redirects to the index.html page now.

 

--------------------------------------------------------------------------------

ME

--------------------------------------------------------------------------------

I'm glad you fixed the errors above. Unfortunately our php includes are still not working properly. I made the loop-outer.php and loop-http-outer.php files to demonstrate the problem. Both files have just one line of code, an include of the loop-inner.php file. The difference is the way in which the include is written, here is what I mean:

######################

http://www.flopturnriver.com/loop-outer.php - works properly because the include is written WITH NO www as follows: include("loop-inner.php");

######################

http://www.flopturnriver.com/loop-http-outer.php - doesn't work, redirects to home page instead of including file because the include is written WITH www as follows: include("http://www.flopturnriver.com/loop-inner.php");

######################

[carbonize]

I know it doesn't solve the problem but it looks to me like you are including files that are on the same web space by using http request but why when an internal include is better and faster?

 

I may be wrong and the files you are including could be on a remote server, if so just tell me to shut up.

[esprague]

Here is more info from the ticket:

 

--------------------------------------------------------------------------------

SUPPORT

--------------------------------------------------------------------------------

Hello Eric,

 

The problem is with the occurance of "www" in it.

 

include("http://flopturnriver.com/loop-inner.php");

 

works

 

but

 

include("http://www.flopturnriver.com/loop-inner.php");

 

fails without any errors.

 

 

--------------------------------------------------------------------------------

Me

--------------------------------------------------------------------------------

That is what I have been saying. It looks like a server permission was changed the night of October 4th such that www is no longer allowed in our php includes. We need this changed back as soon as possible on our dedicated server.

 

We have thousands of pages with these types of includes and some of them cross subdomains. Changing our includes by removing www is not an option.

 

Thanks,

Eric

[esprague]

I know it doesn't solve the problem but it looks to me like you are including files that are on the same web space by using http request but why when an internal include is better and faster?

 

I may be wrong and the files you are including could be on a remote server, if so just tell me to shut up.

carbonize,

 

You're right than in a perfect world an internal include is better. We don't have the resources to go through all our scripts and change them at this time(thousands of pages, issues with global replaces on the right side, single quotes vs double etc). Also, many of our includes cross subdomains and it is complicated sorting things out with subdomains, parameters in the includes, different domains relying on this dedicated server etc.

 

We need to find out what has changed on the server level. As I said these includes have worked fine for years but suddenly they stopped working the morning of October 5th. Obviously something changed outside the scripts and we need to identify and roll back that change.

[carbonize]

I'm wondering if the issue is not with the actual include request but with the server sending back the information. Something like if you get your image hotlinking .htaccess wrong and forget to put in the www. So if people view your site as http://yoursite.com they see the images but if they view as http://www.yoursiet.com they don't.

 

Just a different take on the situation.

[esprague]

I'm wondering if the issue is not with the actual include request but with the server sending back the information. Something like if you get your image hotlinking .htaccess wrong and forget to put in the www. So if people view your site as http://yoursite.com they see the images but if they view as http://www.yoursiet.com they don't.

 

Just a different take on the situation.

If the www problem was our only include issue then I'd say you were on to something. Unfortunately the www issue is the simplest example. In other words, some of our php includes that use parameters have stopped working as well, even when I remove the www from the path.

 

All signs point to something changing on a global level outside the scripts.

 

I like your idea of looking at .htaccess options though. Maybe we could put .htaccess files in each subdomain and subdirectory that has includes if we can override the changed server setting on a directory by directory level. I read about .htaccess on the http://gallery.menalto.com/node/7434 page but I'm still not sure if we should do something there.

 

The php.ini file looks good, I compared it to the php.ini file of another site I have hosted with TotalChoice where the www includes and parameter includes still work fine.

 

What else should we be looking at outside of php.ini and .htaccess? What security and apache settings should we look at?

Edited October 6, 2006 by esprague

[esprague]

I've done some testing removing the www in certain includes. Sometimes it works fine. Other times we have problems.

 

Here is a very simple example of a problem.

 

http://www.flopturnriver.com/myzero.php has one line of code:

><?php include ("http://flopturnriver.com/reviews/average.php?id=37"); ?>

Clicking on http://www.flopturnriver.com/myzero.php in the browser brings up the following:

>Warning: Division by zero in /home/eproxim/public_html/reviews/average.php on line 46
0

 

However, if you just click on http://flopturnriver.com/reviews/average.php?id=37 in the browswer it works fine and shows the numeric average for id 37 which happens to be 3.747 at the time of this writing.

 

Prior to October 5th we always got the same result with our without an include. In other words this division by zero error when using the include is new.

[carbonize]

Whats the code in average.php on line 46?

 

Wonder if slapping this in average.php might help find the problem

<?php

echo '<pre>';

print_r($_SERVER);

echo '</pre>';

?>

Edited October 7, 2006 by carbonize

[esprague]

Whats the code in average.php on line 46?

 

Wonder if slapping this in average.php might help find the problem

<?php

echo '<pre>';

print_r($_SERVER);

echo '</pre>';

?>

 

The average.php file itself only has 16 lines of code but it does a require on a file that has 103 lines. In addition to 103 lines of code, the required file has 2 additional includes.

 

Which php file should we modify to add the print_r($_SERVER); command? What line of code should it go on?

 

Thanks,

Eric

[carbonize]

average.php

 

I was wondering which function is trying to divide by 0.

[esprague]

average.php

 

I was wondering which function is trying to divide by 0.

I just added the code near the top of average.php but it doesn't appear to tell us which function is trying to divide by 0.

[carbonize]

http://www.flopturnriver.com/myzero.php appears to be working as it should now.

[esprague]

http://www.flopturnriver.com/myzero.php appears to be working as it should now.

Vivek fixed it on Oct 7 but now we are having issues again.

 

The problem was that our account was still residing on a shared server but the dns pointed to our dedicated box. Vivek modified the server setup to use an external (cpanel official) nameserver to fix it.

[TCH-Bruce]

Well if it stopped working and you did no updating please open a ticket with the help desk and have then take a look.