PHP Cookie and subfolders problem

Cookie not written on shared hosting, works in VPS

[smallcompany]

I have multiple sites with three hosting companies. With the first two companies I have kind of VPS plans, while with the third one I’m on plain shared hosting.

I have a script that for its end job writes a cookie on users’ machines. The setcookie code is like from school books, and it works fine and 100% on the VPS hosting packages.

setcookie("var1",$v1,$time,"/");
setcookie("var2",$v2,$time,"/");
setcookie("var3",$v3,$time,"/");

The problem is with shared hosting where all works fine only if pages in the root of the site are accessed. If a user lands onto a page in any of the subfolders, no cookie is being written, nor are any of these variables being passed even on the first page.

The setup difference between VPSs and shared hosting (SH) is that on the VPS side I use .htaccess to control PHP include_path and auto_prepend_file, while on SH side I do it through php.ini. I did check that in php.ini relative path is included.
Furthermore, if I run the PHP info on both sides, I get differences like:

Server API – Apache 2.0 Handler on VPS vs. CGI on shared hosting
auto_prepend_file – listed only in Local for VPS vs. both Local and Master in SH
include_path – site root as local and paths to PHP libs as major vs. site root as both Local and Major in SH

PHP version is 5.2.6 in both cases

Would you expect different behavior between these two setups?

Thanks

[penders]

Not sure how this would figure if you say your pages work OK in the root of the site, but... is your SH in the same timezone? It's not 8 hours behind and your cookie is effectively expiring immediately?! (Is the server time correct?)

There are certainly differences between running PHP as an Apache Module as opposed to CGI, although I've not come across a fundamental cookie problem such as this.

auto_prepend_file – listed only in Local for VPS vs. both Local and Master in SH

I think because you are using php.ini on SH (although I assume this is a 'local' php.ini and not the 'master' php.ini that controls the other hosts)?

Have you tried setting the domain as the 5th arg (".example.com")?

Is your SH outputting anything before you setookie()? An error perhaps?

Have you tried setting the cookie header directly?

Are you setting other headers? Is the server setting any additional headers, that your VPS is not? Check the response headers.

Does a simple test page also fail?

[smallcompany]

Thanks for reply.

I did a simple test by putting the script into one of subfolders, and calling it right from the page. It worked!

Then I found "This is not recursive." statement for php.ini. Basically, if I want php.ini to work for the whole site, I have to put it into each directory.

Is this true with each shared hosting?

Thanks

[penders]

Then I found "This is not recursive." statement for php.ini. Basically, if I want php.ini to work for the whole site, I have to put it into each directory.

I'm sure the PHP Manual [uk.php.net] had more info on the use of php.ini (as opposed to .htaccess) when PHP is run as CGI. I thought it was on the Runtime Configuration [uk2.php.net] page, but that page has changed recently, and the information I recall isn't there? Anyway...

I have also read... "place your php.ini file in the dir of your cgi'd php" (if you have access to that directory!?), but I've not tried this.

Is this true with each shared hosting?

No. I think this is because you are running PHP as a CGI binary and not an Apache module, regardless of whether it is a shared host or not.

[smallcompany]

PHP as a CGI binary and not an Apache module

What's the preferred method and why one or another? I only recall I read somewhere that CGI is more secure, but is it?

Thanks.

[penders]

What's the preferred method and why one or another? (Apache Module / CGI)

I don't feel I can really speak authoritatively on this, but IMHO...

I would have said that PHP as an Apache Module is more 'normal' and far more common in a production environment.
- Module is faster and by all accounts is far more configurable.
- CGI can be more secure; but ONLY if set up correctly. If set up incorrectly then it can be a big security hole. (So I've heard.)
- CGI cannot use .htaccess, relying on per directory php.ini files (although I have never been too successful using this method).
- CGI does not support HTTP authentication (apparently).

By all accounts CGI is potentially more restrictive. When people are having issues with their PHP/Server setup, the first question asked is often, "Are you running PHP as CGI?".

Anyone care to disagree/add to this?